[X-Unix] 10.5 cli -what's up with 'more'? [a}

[David Ledger]

At 07:56 +0000 9/12/07, Stroller wrote:
>I've had the mailbounce from this (7kb, limit of 5kb) for a few days 
>- sorry I haven't gotten round to resending it before.

And I've been lighting the village pantomime.

>On 1 Dec 2007, at 18:25, David Ledger wrote:
>>  At 22:37 +0000 30/11/07, Stroller wrote:
>>>  On 30 Nov 2007, at 06:32, David Ledger wrote:
>>>>   That's the way some of the Linux distributions are going - at 
>>>>least, the HP RedHat one is. It's the thing I most dislike about 
>>>>Linux. Lots of people making trivial changes to make it the way 
>>>>*they* think it should be. Under HP RedHat, 'ls' sorts the '.' 
>>>>files amongst the others. Why?
>>>  Are you sure this isn't configured in the distro's default 
>>>.bash_profile or .bashrc? (or /etc/profile?)
>>
>>  Does the same when using /bin/ls, so it's not an inherited alias 
>>or function. I work under ksh with my own aliases pointing back at 
>>/bin/ls anyway.
>
>I don't quite know how to respond to this, because I don't quite 
>understand the symptoms. If you'd like to explain this `ls` sorting 
>a bit better - or give an example of the output? - I'd love to get 
>to the bottom of this & prove that it's a bug (whether the fault of 
>yourself, your distro or GNU, it doesn't matter to me), rather than 
>a feature.

It sorts '.' files as if the '.' were not present - so '.profile' 
sorts into the 'p's rather than between .kshrc and .ssh; which 
themselves are among the 'k's and the 's's.

>Note:
>      (1) If you use a non-POSIX locale (e.g., by setting `LC_ALL' to
>   `en_US'), then `ls' may produce output that is sorted differently than
>   you're accustomed to.  In that case, set the `LC_ALL' environment
>   variable to `C'.
>   [from `info ls`]

Hadn't thought of locale. It will be the default, which is usually 'C'.

>>>  The GNU versions of the "standard utilities" are different from 
>>>those in Posix, System V or the BSDs, but I personally think these 
>>>changes are often (much needed) improvements upon the originals 
>>>and are generally for the best. IMO Bash & the GNU utilis are what 
>>>a modern Unix shouldbe aiming for - it's certainly my expectation 
>>>in terms of ease-of-use.
>>
>>  I've yet to find a change that I would class as a much needed 
>>improvement other than 'tar's new unwillingness to archive from '/'.
>Ok, I don't know about your tar problem (it appears to work fine here)

As I say, that is one improvement. Under 'real' tar, 'tar cf bin.tar 
/bin' would put a tar archive of /bin to file bin.tar; and later 'tar 
xf bin.tar' would only restore to /bin. no way to unarchive to 
/tmp/bin or anywhere else. This often caught people out. The GNU tar 
removes the leading '/' on archiving so that unarchiving creates a 
'bin' directory in the current directory which can be anywhere.

>Looking just at `ls` [1] I can immediately imagine occasions when 
>the '-A", "-b", "-m" and "-i" GNU options could be useful. I admit I 
>can't think of "much needed" improvements off the top of my head, 
>but I bet I could find some if I spent enough time looking. I just 
>don't think a language should stay static just because "this is the 
>way we've always done things".

-A -b and -i are standard back, I think, to Version 6. Changes should 
always be able to be turned off.

>I believe that there few GNU additions that break cross-platform 
>scripts - all GNU utilities that I'm aware of accept POSIX options 
>and it's clearly the intention that they behave correctly when POSIX 
>options are provided.

Unfortunately POSIX compliance has nothing to do with this sort of 
thing. Some version of VMS is POSIX compliant and nothing like Unix 
at the keyboard.

>The --givetheoptionalongnamesopeopleknowwhatitsdoes flags are no 
>specified for exactly that reason.
>Hardly anyone continues to use that format once they're familiar 
>with a command - one will naturally use the "-v" form - but if you 
>use a command infrequently then the long version may be more 
>memorable (not less, as you assert).

Far from all commands have simple flags that correspond to the full 
ones. The long ones are far from memorable, bearing in mind that they 
don't work if you make a minor error. As for emailing, I'm not sure 
where politeness comes in. If 'ls -xyz' is the command then 'ls -xyz' 
is the command. You can always add xmeans ... , y means ... . The 
short form is also less likely to get wrapped.

>If you're using Linux at the enterprise level then doesn't that 
>prove it's ready?   ;)

No. It causes so many problems. What use is a system which, on losing 
connection to storage on the SAN for a few milliseconds (which can 
happen at busy times), decides to change the mount to read-only - the 
only fix being a reboot. Luckily for the users load sharing covers 
the tracks when these errant servers are rebooted, but the service 
does stall for some when it happens.

David


-- 
David Ledger - Freelance Unix Sysadmin in the UK.
HP-UX specialist of hpUG technical user group (www.hpug.org.uk)
david.ledger at ivdcs.co.uk
www.ivdcs.co.uk