fish-users

[Fish-users] configuration lost and request for noclobber in set

[Fernando C. <co...@lu...>]

I just did:

echo 'some handy function definition' > ~/.config/fish/config.fish

Was in a hurry and didn't noticed the '>' instead of '>>', result:
config gone!

2 questions and 1 possible request:

Q1. Is there a way to recover my configuration by perusing the actual
environment? I have several terms opened and machine wont go off (I
hope). Already recovered my functions by doing a:

functions -a > fish.functions.all.bak

But I don't know an easy way to recover environment variables without
going one by one. I listed the __fish_complete functions, but I were
unable to find the one the completes a '$<TAB>' keystroke. If I could
find a way to get all environment variable names I could save them all.

Q2. Is there some way to emulate this from bash:

set -o noclobber

that set disables '>' to overwrite existing files (and you can bypass it
also, so is pretty useful)

Possible Request: if there's no way to achieve Q2, what about including
it in the next fish release? I think that set is in the spirit of fish.

-- 
Fernando Canizo - http://muriandre.homelinux.org/~conan/

Re: [Fish-users] configuration lost and request for noclobber in set

[Axel L. <lil...@gm...>]

On 10/10/07, Fernando Canizo <co...@lu...> wrote:
> I just did:
>
> echo 'some handy function definition' > ~/.config/fish/config.fish
>
> Was in a hurry and didn't noticed the '>' instead of '>>', result:
> config gone!

Ouch. I'm sorry to hear that.

>
> 2 questions and 1 possible request:
>
> Q1. Is there a way to recover my configuration by perusing the actual
> environment? I have several terms opened and machine wont go off (I
> hope). Already recovered my functions by doing a:
>
> functions -a > fish.functions.all.bak
>
> But I don't know an easy way to recover environment variables without
> going one by one. I listed the __fish_complete functions, but I were
> unable to find the one the completes a '$<TAB>' keystroke. If I could
> find a way to get all environment variable names I could save them all.

There is no way to get the exact definition of the config file, but
you can get a listing of all current variable definitions.

Just use the 'set' command to list currently defined variables. You
can filter the output to only show exported variable using 'set -x'
and so on. You'll have to go over the list manually and remove things
that you sholdn't set yourself, like PATH.

That said, there aren't many situations where the config.fish is the
easiest way to configure fish. The 'right' way to define functions is
a two-step process:

* First, try out the function be defining it on the commandline, e.g.
'function woot; echo woot!; end'.

* Secondly, use 'funcsave woot' (if your function is named 'woot',
that is)  to save the function into the ~/.config/fish/functions
directory. (funcsave used to be called save_function, I don't remember
exactly when the renaming happened, YMMV)

This has a few benefits:

* You can try out the function until you get it just right.

* You don't accidentally delete your config file.;-)

* All the other running shells will automatically have access to your
new function.

* If you update the definition of an existing function, all running
shells will automatically reload it when needed.

Defining variables in the config file is also something you should
very rarely have to do, since you can use universal variables most of
the time. See 'help variables' for more information on universal
variables and how to use them.

>
> Q2. Is there some way to emulate this from bash:
>
> set -o noclobber
>
> that set disables '>' to overwrite existing files (and you can bypass it
> also, so is pretty useful)
>
> Possible Request: if there's no way to achieve Q2, what about including
> it in the next fish release? I think that set is in the spirit of fish.

Unfortunatly, that is not currently possible. I am not a big fan of
configuration options, so I am a bit hesitant about making the way IO
redirections perform be configurable. I see the value in what you
propose, but if possible I'd rather try to figure out another way to
reach the same goal.

> --
> Fernando Canizo - http://muriandre.homelinux.org/~conan/
>

Axel

Re: [Fish-users] configuration lost and request for noclobber in set

[Axel L. <lil...@gm...>]

On 10/19/07, Martin B=E4hr <mb...@em...> wrote:
> On Fri, Oct 19, 2007 at 01:01:35PM +0200, Beni Cherniavsky wrote:
> > 0. Now: Allow ">?" or "?>" and ">!" or "!>" to explicitly mean
> > noclobber, and encourage people to rewrite scripts.
>
> i have been wondering about a syntax for an explicit noclobber.
>
> >? or ?> look good.
>
> generally though i'd prefer not to change > for consistency.
> my main concern is: i'll get used to > not overwriting a file and then
> when i work in a different shell (because fish is not on every machine),
> i'll likely forget that > is different and get bitten by it.

At least zsh and bash already support a noclobber option, though like
pretty much every useful shell feature in the universe, it is disabled
by default. I don't know how many people manually enable it. My
experience tells me that very few people have enough energy to go
through the huge list of configuration options and enable the ones
they like.

Axel

>
> (for the same reason i hate it when distributions make rm an alias to rm =
-i.
> i'll get used to rm always asking if it should really remove the file,
> that i'll adopt a habit of always using rm -f, and thereby hiding cases
> where a file has write permissions removed.)
>
> greetings, martin.
> --
> cooperative communication with sTeam      -     caudium, pike, roxen and =
unix
> offering: programming, training and administration   -  anywhere in the w=
orld
> --
> pike programmer   working in new zealand        open-steam.org|webhaven.c=
o.nz
> unix system-      bahai.or.at                        iaeste.(tuwien.ac|or=
).at
> administrator     (caudium|gotpike).org                          is.schon=
.org
> Martin B=E4hr       http://www.iaeste.or.at/~mbaehr/
>

Re: [Fish-users] configuration lost and request for noclobber in set

[Martin <mb...@em...>]

On Sat, Oct 20, 2007 at 03:23:48PM +0200, Axel Liljencrantz wrote:
> experience tells me that very few people have enough energy to go
> through the huge list of configuration options and enable the ones
> they like.

right, and changing the default does not help me, when i get into a
random shell on someone elses machine, where i am asked to help solve a
problem. i can't spend a lot of time configuring stuff when i am using
the machine only for a few minutes. i need to rely on sane defaults.
(fish is helping a lot here, even though i regret discovering that i
use the shell not nearly as much as i thought i would :-)

greetings, martin.
-- 
cooperative communication with sTeam      -     caudium, pike, roxen and unix
offering: programming, training and administration   -  anywhere in the world
--
pike programmer   working in new zealand        open-steam.org|webhaven.co.nz
unix system-      bahai.or.at                        iaeste.(tuwien.ac|or).at
administrator     (caudium|gotpike).org                          is.schon.org
Martin Bähr       http://www.iaeste.or.at/~mbaehr/

Re: [Fish-users] configuration lost and request for noclobber in set

[Fernando C. <co...@lu...>]

Axel Liljencrantz wrote:
> On 10/10/07, Fernando Canizo <co...@lu...> wrote:
>> I just did:
>>
>> echo 'some handy function definition' > ~/.config/fish/config.fish
>>
>> Was in a hurry and didn't noticed the '>' instead of '>>', result:
>> config gone!
> 
> Ouch. I'm sorry to hear that.

yeah, ouch, more on this at the end since clobbering files is something
I wanna discuss in deep.

> There is no way to get the exact definition of the config file, but
> you can get a listing of all current variable definitions.
> 
> Just use the 'set' command to list currently defined variables. You
> can filter the output to only show exported variable using 'set -x'
> and so on. You'll have to go over the list manually and remove things
> that you sholdn't set yourself, like PATH.

What does this mean exactly? What's the issue with PATH? Why shouldn't
set it *myself*?

I was messing around with PATH and I cannot add my local directories
(aka: /usr/local/bin /home/conan/bin) which contains some handy scripts
for my day to day work. I can do a 'set -l' but I don't know if that's
the right thing to do.

> That said, there aren't many situations where the config.fish is the
> easiest way to configure fish. The 'right' way to define functions is
> a two-step process:

You have opened a new path of discovery for me with that, I was using
fish like bash, with a big configuration file full of stuff here and
there, now I have reduced it to this:

$ cat .config/fish/config.fish
umask 077

if status --is-interactive
	command fortune
end

> This has a few benefits:
> * You can try out the function until you get it just right.
> * You don't accidentally delete your config file.;-)
> * All the other running shells will automatically have access to your
> new function.
> * If you update the definition of an existing function, all running
> shells will automatically reload it when needed.

Last two totally worth the money :)

>> Q2. Is there some way to emulate this from bash:
>>
>> set -o noclobber
>>
>> that set disables '>' to overwrite existing files (and you can bypass it
>> also, so is pretty useful)
>>
>> Possible Request: if there's no way to achieve Q2, what about including
>> it in the next fish release? I think that set is in the spirit of fish.
> 
> Unfortunatly, that is not currently possible. I am not a big fan of
> configuration options, so I am a bit hesitant about making the way IO
> redirections perform be configurable.

Indeed, I forgot when I wrote it that another thing in fish philosophy
is to try to avoid configurabilititis. So:

> I see the value in what you
> propose, but if possible I'd rather try to figure out another way to
> reach the same goal.

First thing I tried was to make it a function, dead end there. So here
is what I've thought.

When using > there are two possible cases relating to file creation/writing:

1. what to do if file doesn't exists
2. what to do if file exists

In the former case solution is simple: create the file and write to it.
But in case 2 there are 3 possible courses of action:

a. overwrite the file (current default, and default for others shells too)
b. append to the file
c. refuse to write to the file

Now 'a' is what I'm trying to avoid. 'b' can be eliminated from the
picture since we already have '>>'. 'c' is what I think should be the
default for a shell which claims to be "friendly" and to be consistent
with this sentence: "But even well designed, powerful programs sometimes
need to be updated to remove some of the old mistakes."

:)

The only thing left is that sometimes one will really want to truncate a
file. In bash this is achieved with this syntax (when noclobber is set):

echo "nothing" >| file_to_be_truncated

Now the syntax could be anything, it's not important, but it's important
to have a way to overcome the default.

And voilá, no configuration needed. Just sane defaults.

I ask you kindly to give this issue a second thought. Programs should
not eliminate your precious data. We, humans, make mistakes.


-- 
Fernando Canizo - http://muriandre.homelinux.org/~conan/

Re: [Fish-users] configuration lost and request for noclobber in set

[Philip G. <phi...@gm...>]

On 10/17/07, Fernando Canizo <co...@lu...> wrote:
[when the file exists, you can either]
> a. overwrite the file (current default, and default for others shells too)
> b. append to the file
> c. refuse to write to the file
>
[...] 'c' is what I think should be the
> default for a shell which claims to be "friendly" and to be consistent
> with this sentence: "But even well designed, powerful programs sometimes
> need to be updated to remove some of the old mistakes."

In other words, it's as if the noclobber option is hardwired to be
set, and another redirect operator is created for overwriting.  I
think this is better than overwriting by default.

Re: [Fish-users] configuration lost and request for noclobber in set

[Chris R. <cvr...@gm...>]

If this idea is accepted, I'd like to propose "!>" and "!^" as the
overwriting versions of the IO redirect operators, the exclamation point or
"bang" signifying "overwrite!". From a quick glance at the fish docs, "!"
currently has no special meaning in the shell, so it's available for this
use.

- Chris Rebert


On 10/17/07, Philip Ganchev <phi...@gm...> wrote:
>
> On 10/17/07, Fernando Canizo <co...@lu...> wrote:
> [when the file exists, you can either]
> > a. overwrite the file (current default, and default for others shells
> too)
> > b. append to the file
> > c. refuse to write to the file
> >
> [...] 'c' is what I think should be the
> > default for a shell which claims to be "friendly" and to be consistent
> > with this sentence: "But even well designed, powerful programs sometimes
> > need to be updated to remove some of the old mistakes."
>
> In other words, it's as if the noclobber option is hardwired to be
> set, and another redirect operator is created for overwriting.  I
> think this is better than overwriting by default.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Fish-users mailing list
> Fis...@li...
> https://lists.sourceforge.net/lists/listinfo/fish-users
>

[Fish-users] configuration lost and request for noclobber in set

[Axel L. <lil...@gm...>]

This mail is a few hours old as this is a forward of a correspondance
that accidentally ended up private. Ignore the slight redundancy! :)

On 10/17/07, Fernando Canizo <co...@lu...> wrote:
> Axel Liljencrantz wrote:
> > On 10/10/07, Fernando Canizo <co...@lu...> wrote:
> >> I just did:
> >>
> >> echo 'some handy function definition' > ~/.config/fish/config.fish
> >>
> >> Was in a hurry and didn't noticed the '>' instead of '>>', result:
> >> config gone!
> >
> > Ouch. I'm sorry to hear that.
>
> yeah, ouch, more on this at the end since clobbering files is something
> I wanna discuss in deep.
>
> > There is no way to get the exact definition of the config file, but
> > you can get a listing of all current variable definitions.
> >
> > Just use the 'set' command to list currently defined variables. You
> > can filter the output to only show exported variable using 'set -x'
> > and so on. You'll have to go over the list manually and remove things
> > that you sholdn't set yourself, like PATH.
>
> What does this mean exactly? What's the issue with PATH? Why shouldn't
> set it *myself*?

I was rather unclear. Fish will inherit a PATH from it's parent, and
then the internal init script of fish itself might add more elements.
It is perfectly reasonable to add and remove elements of PATh, but you
rarely want to redefine it wholesale.

> I was messing around with PATH and I cannot add my local directories
> (aka: /usr/local/bin /home/conan/bin) which contains some handy scripts
> for my day to day work. I can do a 'set -l' but I don't know if that's
> the right thing to do.

Keep in mind that in fish, PATH is an array variable, with one element
per directory.

You add an element like this:

set PATH $PATH /some/new/directory

You can remove an element like this:

set -e PATH[3]

If you tried to make PATH colon-separated, like in bash, you should
have gotten an error message like this one:

set: Could not add component /usr/local/sbin:/some/directory to PATH.
set: No such file or directory
set: Did you mean 'set PATH $PATH /some/directory'?

>
> > That said, there aren't many situations where the config.fish is the
> > easiest way to configure fish. The 'right' way to define functions is
> > a two-step process:
>
> You have opened a new path of discovery for me with that, I was using
> fish like bash, with a big configuration file full of stuff here and
> there, now I have reduced it to this:
>
> $ cat .config/fish/config.fish
> umask 077
>
> if status --is-interactive
>         command fortune
> end
>
> > This has a few benefits:
> > * You can try out the function until you get it just right.
> > * You don't accidentally delete your config file.;-)
> > * All the other running shells will automatically have access to your
> > new function.
> > * If you update the definition of an existing function, all running
> > shells will automatically reload it when needed.
>
> Last two totally worth the money :)

:-D

>
> >> Q2. Is there some way to emulate this from bash:
> >>
> >> set -o noclobber
> >>
> >> that set disables '>' to overwrite existing files (and you can bypass =
it
> >> also, so is pretty useful)
> >>
> >> Possible Request: if there's no way to achieve Q2, what about includin=
g
> >> it in the next fish release? I think that set is in the spirit of fish=
.
> >
> > Unfortunatly, that is not currently possible. I am not a big fan of
> > configuration options, so I am a bit hesitant about making the way IO
> > redirections perform be configurable.
>
> Indeed, I forgot when I wrote it that another thing in fish philosophy
> is to try to avoid configurabilititis. So:
>
> > I see the value in what you
> > propose, but if possible I'd rather try to figure out another way to
> > reach the same goal.
>
> First thing I tried was to make it a function, dead end there. So here
> is what I've thought.
>
> When using > there are two possible cases relating to file creation/writi=
ng:
>
> 1. what to do if file doesn't exists
> 2. what to do if file exists
>
> In the former case solution is simple: create the file and write to it.
> But in case 2 there are 3 possible courses of action:
>
> a. overwrite the file (current default, and default for others shells too=
)
> b. append to the file
> c. refuse to write to the file
>
> Now 'a' is what I'm trying to avoid. 'b' can be eliminated from the
> picture since we already have '>>'. 'c' is what I think should be the
> default for a shell which claims to be "friendly" and to be consistent
> with this sentence: "But even well designed, powerful programs sometimes
> need to be updated to remove some of the old mistakes."
>

Dang it. No fair, using my own arguments against me.

> :)
>
> The only thing left is that sometimes one will really want to truncate a
> file. In bash this is achieved with this syntax (when noclobber is set):
>
> echo "nothing" >| file_to_be_truncated
>
> Now the syntax could be anything, it's not important, but it's important
> to have a way to overcome the default.

That works very well, but there is one problem. Fish allows you to
redirect any file descriptor to a pipe using something like:

make 2>| less

The above will use the less pager to scroll through the output of
make. But that clashes with the suggested syntax for clobbering files.
We could chose to use something other than bash does, but when it
comes to picking arbitrary squiggles for operators, I see a pretty
strong benefit in making the same choices as the shell that must not
be named does in order to make migration between shells easier.

We could switch the pipe redirection to be 'make 2| less', though that
will mean that scripts like 'cat *.foo|cut -f 2|head' will bug out.
That was the original reason for chosing '2>|' instead of '2|'.

>
> And voil=E1, no configuration needed. Just sane defaults.
>
> I ask you kindly to give this issue a second thought. Programs should
> not eliminate your precious data. We, humans, make mistakes.

Right.

You've convinced me that this is worth trying to change.

Axel

>
>
> --
> Fernando Canizo - http://muriandre.homelinux.org/~conan/
>

Re: [Fish-users] configuration lost and request for noclobber in set

[Kurt H. <kel...@gm...>]

On 10/17/07, Philip Ganchev <phi...@gm...> wrote:
> In other words, it's as if the noclobber option is hardwired to be
> set, and another redirect operator is created for overwriting.  I
> think this is better than overwriting by default.

I just wanted to add another vote for "noclobber by default". When I
used zsh, I always had the option set to save myself from myself. It
saved me a number of times, and is not too annoying to override.


On 10/17/07, Chris Rebert <cvr...@gm...> wrote:
> If this idea is accepted, I'd like to propose "!>" and "!^" as the
> overwriting versions of the IO redirect operators, the exclamation point or
> "bang" signifying "overwrite!". From a quick glance at the fish docs, "!"
> currently has no special meaning in the shell, so it's available for this
> use.

zsh also has a similar syntax to force overwriting, but with the
exclamation following: >!
Whether leading or following, I agree with using the exclamation as
syntax for clobbering.

Re: [Fish-users] configuration lost and request for noclobber in set

[Myrddin E. <my...@gm...>]

I'd like to put my vote in for 'noclobber by default'.

That said, I can understand Axel's reticence...  > and >> are fundamental
shell features that almost everyone uses frequently. The more you use
something, the more ingrained it becomes, and the harder it is to imagine it
working differently. I myself have never clobbered a file by accident, but I
can see it happening, and I can clearly see where it would be valuable to
avoid.

Personally, I'm in favor of the !> (or >!) syntax (as long as that doesn't
cause parser problems). In several languages the ! is used to indicate
dangerous or destructive commands (the most recent one I recall being ruby),
so it would make semantic sense to me.

Obviously, you'd want a help message to say 'I'm sorry, this file already
exists and is non-zero in length. Use !> to force an overwrite of the file.'

Myrddin

Re: [Fish-users] configuration lost and request for noclobber in set

[Philip G. <phi...@gm...>]

On 10/17/07, Axel Liljencrantz <lil...@gm...> wrote:
[...]
> On 10/17/07, Fernando Canizo <co...@lu...> wrote:
[...]
> > The only thing left is that sometimes one will really want to truncate a
> > file. In bash this is achieved with this syntax (when noclobber is set):
> >
> > echo "nothing" >| file_to_be_truncated
> >
> > Now the syntax could be anything, it's not important, but it's important
> > to have a way to overcome the default.
>
> That works very well, but there is one problem. Fish allows you to
> redirect any file descriptor to a pipe using something like:
>
> make 2>| less
>
> The above will use the less pager to scroll through the output of
> make. But that clashes with the suggested syntax for clobbering files.
> We could chose to use something other than bash does, but when it
> comes to picking arbitrary squiggles for operators, I see a pretty
> strong benefit in making the same choices as the shell that must not
> be named does in order to make migration between shells easier.

The trouble is the 'noclobber' option in the shell that shall not be
named. It makes the '>' operator modal, so when people write '>' they
expect something different if they are used to having the option set
than if they are not.  Since we don't want to replicate this bad
effect in Fish, whatever '>' means in Fish, it will be incompatible
with other shells for some users.

So another solution is to habituate to using tab completion to avoid
overwriting the file.  If the file name completes, then the file
exists and you are about to overwrite it.

Re: [Fish-users] configuration lost and request for noclobber in set

[Myrddin E. <my...@gm...>]

On 10/18/07, Philip Ganchev <phi...@gm...> wrote:
>
> The trouble is the 'noclobber' option in the shell that shall not be
> named. It makes the '>' operator modal, so when people write '>' they
> expect something different if they are used to having the option set
> than if they are not.


Modality isn't quite as bad as all that, since Fish has the facilities for
excellent just-in-time help. Whenever fish misbehaves for me, it tells me
why, and often exactly where I need to go to figure it out.

# echo foo > bar
Error: file exists, and noclobber is set. Use !> to overwrite the file, or
type help noclobber for more information.

Re: [Fish-users] configuration lost and request for noclobber in set

[Beni C. <cb...@us...>]

On 10/19/07, Myrddin Emrys <my...@gm...> wrote:
> On 10/18/07, Philip Ganchev <phi...@gm...> wrote:
> > The trouble is the 'noclobber' option in the shell that shall not be
> > named. It makes the '>' operator modal, so when people write '>' they
> > expect something different if they are used to having the option set
> > than if they are not.
>
> Modality isn't quite as bad as all that, since Fish has the facilities for
> excellent just-in-time help. Whenever fish misbehaves for me, it tells me
> why, and often exactly where I need to go to figure it out.
>
> # echo foo > bar
> Error: file exists, and noclobber is set. Use !> to overwrite the file, or
> type help noclobber for more information.
>
Unconvincing - if noclobber was off in the above example you would get
no help (and no file ;-).

But the real reason that modality is very bad lies in shell scripts.
Remember that the shell is not always used in a tight type-execute
feedback loop.  Someone writes a script that works for him in fish
dialect A (noclobber off); 2 years later someone other will run the
script under fish dialect B (noclobber on) and will have no idea why
the script didn't work.

To avoid this, you will have to remember to specify all dialect
options at the beginning of every script, and even then people would
get surprises when they cut-and-paste between scripts and the command
line.

Sadly, the above scripts breakage scenario is bound to occur once now,
if we change the definition of ">".  But in the long term, we will be
better off after the change.
Perhaps we can ease the compatibility problem with a transition plan:

0. Now: Allow ">?" or "?>" and ">!" or "!>" to explicitly mean
noclobber, and encourage people to rewrite scripts.
1. Next version: warn that behaviour will change when ">" is used with
an existing file.
   Optional: warn for any use of ">" in scripts?
2. Post-next version: change behaviour of ">" to mean ">?".
3. Far future: optionally remove ">?" to avoid two ways to spell the same thing?

Step 1 could be done together with 0 if we are eager and the warning
is mostly harmless (e.g. stderr and only if it goes to a terminal?).

But step 3 would discourage rewriting scripts in step 1.  I say we
should leave ">?" legal forever because it looks good in scripts,
explicitly hinting to people who come from other shells that we mean
noclobber.  Perhaps ideally we should transition to ">?" and ">!"
only, removing ">" altogether, but we can't afford it:
* It would surprise people who assume ">" works somehow in all shells!
* It would be inconvenient to type all the time.
* It would lose the safety benefit of making the shortest operator ">"
the noclobber one, which is the main reason we want to make a change
at all.

Two side notes:

* ">?" and "?>" both conflict with wildcard syntax.  But I think the
danger of someone writing "ls ?>one-letter-files" or "ls>?.out" are
negligable, especially the later (I've never seen anyone redirect to a
glob, mainly because it's undefined when there are multiple matches).

* What exactly should ">"/">?" do when the file exists?  Just failing
is good for a single command (because we can check the redirection
before we exec the commands) but perhaps not friendly enough in the
middle of a script or loop.  Perhaps fish should stop and ask the user
for confirmation, if stdin/stderr go to a terminal?

--
Beni Cherniavsky <cb...@us...> (I read email only on weekends)


-- 
Beni Cherniavsky <cb...@us...> (I read email only on weekends)

Re: [Fish-users] configuration lost and request for noclobber in set

[Nicholas B. <nic...@ma...>]

On Oct 19, 2007, at 4:01 AM, Beni Cherniavsky wrote:

>
> Sadly, the above scripts breakage scenario is bound to occur once now,
> if we change the definition of ">".  But in the long term, we will be
> better off after the change.


I'd like to cast my vote for not changing the ">" semantics. There's  
something to be said for staying somewhat consistent with what other  
shells do. While those of us who use fish daily and have it installed  
on all of our machines will be able to pick up the new semantics  
quickly, new users may be unpleasantly surprised when ">" fails to  
overwrite a file.

Just my $0.02.

-Nick

Re: [Fish-users] configuration lost and request for noclobber in set

[Martin <mb...@em...>]

On Fri, Oct 19, 2007 at 01:01:35PM +0200, Beni Cherniavsky wrote:
> 0. Now: Allow ">?" or "?>" and ">!" or "!>" to explicitly mean
> noclobber, and encourage people to rewrite scripts.

i have been wondering about a syntax for an explicit noclobber.

>? or ?> look good.

generally though i'd prefer not to change > for consistency.
my main concern is: i'll get used to > not overwriting a file and then
when i work in a different shell (because fish is not on every machine), 
i'll likely forget that > is different and get bitten by it.

(for the same reason i hate it when distributions make rm an alias to rm -i.
i'll get used to rm always asking if it should really remove the file,
that i'll adopt a habit of always using rm -f, and thereby hiding cases
where a file has write permissions removed.)

greetings, martin.
-- 
cooperative communication with sTeam      -     caudium, pike, roxen and unix
offering: programming, training and administration   -  anywhere in the world
--
pike programmer   working in new zealand        open-steam.org|webhaven.co.nz
unix system-      bahai.or.at                        iaeste.(tuwien.ac|or).at
administrator     (caudium|gotpike).org                          is.schon.org
Martin Bähr       http://www.iaeste.or.at/~mbaehr/