Re: qshell, ls, sort by size

As was pointed out /six days ago/, now... you could easily do this:

ls -al | sort +4 -r

This code will work on an Unix system I'm aware of.

to get the directory sorted the way you want it. Or, if you can't stand typing that much, you could type this:

alias lsz="ls -al | sort +4 -r"

(You could put that into a script that's run when you start QShell so you don't have to type it each time) now whenever you like, you can sort by size by typing:

lsz

I really think this discussion is making a mountain out of a molehill. It was a problem that was SOOOO easy to solve. I'm having a tough time with this thread.


CRPence wrote:

Hans Boldt wrote:

Scott Klement wrote:

<<SNIP>>

My point is that -S isn't "standard." It's a popular (and, arguably useful) extension to -S. But it's not a standard, and therefore not a bug. A poor design decision? Absolutely, I'll
accept that. But I can't see IBM considering it a bug.

Agreed. As I said before (or perhaps just strongly implied), IBM can't fix ls in qshell.

To say "IBM can't" I believe is too strong. I know there have been many incompatible changes which had been made for significantly lesser reasons. Sadly many such changes were actually side effects of poor decisions, side effects of code changes or design, which became de facto /function/, only due to those side effects not being noticed until after some might have since become dependent on them. The track record for IBM may be very good for ensuring forward compatibility, but incompatible changes are merely rare; i.e. they do in fact occur, and are best [& often] documented in the MTU for a release, to give the opportunity to prepare for the upcoming impact by that change. I actually considered the choice of compatibility aspect, so consistently over correcting an improper behavior, to be very frustrating as a developer. However it all comes down to... One need only suffer from a lack of creativity to assume a computer can not be programmed to allow system or user preference. Reality may offer fewer choices for effecting that [e.g. lack of resources to provide the interface to configure choice], but the possibility still exists. For example...

It would be easy enough to add an environment variable which could define that -S would effect /sort by size/ versus /CCSID info/ and that some alternate flag would be defined to effect /CCSID info/. Or even by the existence of such an environment variable, that the character value of that environment variable defines the alternative as flag to request CCSID information. In this manner the upward compatibility is maintained, and only those implementing the data area get the new behavior. There is also the option of making the changed behavior the new default action, while having a similar environment variable which enables reset to the original\old action; i.e. the incompatible change.

Regards, Chuck