Andreas Schwab wrote:
> Niels Möller writes:
> > why the option character 'f' (force) is selected for that.
>
> That 'f' probably stands for 'fast' (from the days when sorting was deemed
> expensive).
Like yourself I had always assumed it was meant to be "fast" for
exactly the reason you said. But now I think it really is "force".
Which is different from the way GNU ls currently behaves.
The V7 manual says:
-f Force each argument to be interpreted as a directory and list
the name found in each slot. This option turns off -l, -t, -s,
and -r, and turns on -a; the order is the order in which entries
appear in the directory.
The online standards say:
-f [XSI] Force each argument to be interpreted as a directory and
list the name found in each slot. This option shall turn off -l,
-t, -s, and -r, and shall turn on -a; the order is the order in
which entries appear in the directory.
If I compile up the v7 ls.c source into a running program and try it
then the behavior is that of forcing a file to be read as a
directory.
ls-v7 -f .
...ls output...
cat . > testfile
ls-v7 -f testfile
...same ls output...
The old 'ls' reads the file as if it were a directory.
Trying this on HP-UX ls [Anyone have a Solaris system?] I see:
/bin/ls -f testfile # even as root
testfile unreadable
It looks to me like somewhere along the way the -f option lost the
ability to force files to be read as directories. The standards docs
appear to still follow the old behavior so the capability still
appears to be required as an XSI extension. But not really being too
well used this has probably not been noticed by anyone for ages.
Anyone feel like filing a request for clarification in the standard?
I would guess that in the original 'ls' this feature was there for
debug and development of 'ls' itself. It seems like it would be
useful for that purpose.
Bob
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
