Am 10.02.2012 17:41, schrieb Gavin Atkinson: > On Fri, 2012-02-10 at 11:25 -0500, Eitan Adler wrote: >> Picking a random email to reply to. >> >> My goal with this email is to reduce the amount of "controversial" changes. > > I applaud this. I've often considered doing the same but avoided it > because it was easier than fighting the bikeshed :) > >> commit 3ea4ea3a59d14cb060244618dd89d7dd0170bee1 >> diff --git a/etc/root/dot.cshrc b/etc/root/dot.cshrc >> --- a/etc/root/dot.cshrc >> +++ b/etc/root/dot.cshrc >> _at__at_ -7,9 +7,10 _at__at_ >> >> alias h history 25 >> alias j jobs -l >> -alias la ls -a >> +alias la ls -aF >> alias lf ls -FA >> -alias ll ls -lA >> +alias ll ls -lAF >> +alias ls ls -F >> >> Two people didn't like these changes but didn't explain why. This is >> incredibly helpful, especially for a new user. If you dislike the >> alias change please explain what bothers you about it? > > I don't use the first two aliases, so I don't care about them at all. I > do however disagree strongly with changing the default options on such a > widely used command. Those aliases are only meant for interactive use and should be hidden in batch shells, IMO. > This change is disruptive, and it can affect use of ls(1) in scripts. > For example, it even sticks the extra characters in the output of > "ls -1" (the number 1), which is specifically designed to be used when > piping the output elsewhere. Please do not break this. It is also > distracting - If I want to see what type of file a particular entry is, > why not just run "ls -l"? Yes, having -F modify the output of "ls -1" is bad ... But "ls -l" is no replacement for "ls -F", in general. > It's like the tendency some Linux distributions have of > "alias mv mv -i", although that can at least be overridden on the > command line with "-f". The "ls -F" change cannot be overridden without > unaliasing. Well, it can ... There is no need to unalias a command: > alias ls ls -F > ls -d /etc /etc/ > \ls -d /etc /etc Just put a back-slash before the command to use the "pure" version ... Regards, STefanReceived on Fri Feb 10 2012 - 16:54:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC