Commands with options: (was: war story: parallel(1) command)

[D. Hugh Redelmeier]

| From: phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org

| Interesting read. Unfortunately, the concept of 'lots of small tools that
| do one job well' instead of 'zillions of options' leads to two
| alternatives:
| 
| 1. Concatenate a series of small programs or shell script symbols to do
| the job you want, or

Yes, if what you want is a little intricate.  Most things are pretty
simple so the sequence needed are pretty short.

| 2. Hide that construction in an alias.

alias is an abomination from csh.  BSD is the root of a lot of rot in
UNIX (the paper I pointed at was part of that ancient battle, long
lost).  BSD folks added a lot of useful things to UNIX (eg. networking,
paging, csh, vi), but their lack of adoption of UNIX style is evident,
even from those things.

| The disadvantage of 1 is that the incantation is often hard to remember.

This is part of the UNIX way: you understand primitives and how to
string them together to achieve interesting results.  You don't
memorize recipes.  Designed by and for programmers.

Some tricks are surprising and are worth learning because they might
not be discovered on demand.

| My (un)favourite example: the ls command has no option to display only
| directories.

I've always used
	ls -d */.
I invented this before "ls -d */" worked.

This is a composition of two features, albeit in one command.  -d
means list the directory, not its contents.  */. matches the . entry
in each director, which means the directory itself.

| Yes, there are alternatives, but should you have to commit
| something like this to memory: 'ls -p |grep /' ? Surely something like ls
| -D would be easier to remember.

You don't memorize, you compose, from a well-understood palette.
That's why the unreasonable growth of section 1 of the manual is so
burdensome.

If you want to do things in greater generality, there is always
find(1) -- I do admit that it is ugly.  And in this case, you appear
to not want to descend into subdirectories, so it isn't that useful.

| Incidentally, for me the most useable solution for identifying directories
| has been
| ls -colour | more.
| The directories are a different colour. However, I suspect that's not
| totally portable either.

Does that work?  On my machine, you have to spell it the American way.

Fedora seems to provide an alias for ls that I detest (from
/etc/profile.d/colorls.sh):
	alias ls='ls --color=tty' 2>/dev/null

Why do I dislike this?

- it wasn't what I'm used to

- it was foisted on me without announcement

- for many screens, it is very hard to read text in several of the
  colours chosen

- ls doesn't pay attenting to TERM=.  In particular, I frequently use
  ls in a Jove terminal window which doesn't support colour; this is
  announced in $TERM and ignored by ls.

grep too has been aliased to display coloured results.

| From: phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org

| ls -colour works, the directories are a different colour.

Really?  I think you need double dash and US spelling
  ls --color

Surprisingly, -colour does have a meaning (as multiple flags):
    -c show ctime
    -o like -l, but don't show group information
    -l long listing format
    -o same again
    -u show access time
    -r reverse the order


| ls -colour | more does not work, the directories are the same colour.

--color=TTY says use colour when the output is to a tty.  Not a pipe.
As mentioned above, this heuristic is wrong since it ignores $TERM.

| ls -d is claimed in the manual entry to list directories, but it just
| lists the current directory.

"list directory entries instead of contents, and do not
dereference symbolic links"

| Has anyone actually used this feature?

Certainly.

| Interestingly ls -d /* does list directories...and in colour.

It will list all the files in the root directory (excluding those with
names starting with .), not just the directories.

| From: Chris F.A. Johnson <chris-E7bvbYbpR6jSUeElwK9/Pw at public.gmane.org>

(I mostly agree with you.)

| > That's much easier to remember, but my understanding is that only works in
| > bash.
| 
|   It works in any shell except a very old Bourne shell.

Really?  I thought it was a change to filesystem semantics.  My
(vague, unreliable) recollection is that it came in with BSD.  Note:
it doesn't require globing to get the effect:
	ls -d './'

I guess what is part of globbing is that */ only matches directories.

Summary: "x/" is roughly the same as "x/."

|    --colour is a GNU option.

I think that --colour is unrecognized.  At least on my Fedora and
Ubuntu systems.  --color is recognzed.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists