Re: Documentation discrepancy for ls -f
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
Re: Documentation discrepancy for ls -f
[EMAIL PROTECTED] (Niels Möller) writes: > while the message from ls --help says > > -f do not sort, enable -aU, disable -lst > > This differs with respect to the -t and --color options. That -f > disables --color seems to match the implementation. Thanks for reporting that. I installed the patch below. > I think it would also be helpful to say something about what -f is > intended to be used for and why the option character 'f' (force) is > selected for that. Sorry, I don't know that one. > should I use bug-coreutils instead? Yes, please. 2006-03-05 Paul Eggert <[EMAIL PROTECTED]> * src/ls.c (usage): Mention that -f disables --color. Problem reported by Niels Möller. --- ls.c26 Feb 2006 10:01:00 - 1.406 +++ ls.c6 Mar 2006 07:02:39 - 1.407 @@ -4152,7 +4152,7 @@ Mandatory arguments to long options are -D, --diredgenerate output designed for Emacs' dired mode\n\ "), stdout); fputs (_("\ - -f do not sort, enable -aU, disable -lst\n\ + -f do not sort, enable -aU, disable -ls --color\n\ -F, --classify append indicator (one of */=>@|) to entries\n\ --file-typelikewise, except do not append `*'\n\ --format=WORD across -x, commas -m, horizontal -x, long -l,\n\ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Documentation discrepancy for ls -f
I this still the right place to send bug-reports for GNU ls? Or should I use bug-coreutils instead? I'm using "ls (GNU fileutils) 4.0". The info documentation has the following to say about -f: `-f' Primarily, like `-U'--do not sort; list the files in whatever order they are stored in the directory. But also enable `-a' (list all files) and disable `-l', `--color', and `-s' (if they were specified before the `-f'). while the message from ls --help says -f do not sort, enable -aU, disable -lst This differs with respect to the -t and --color options. That -f disables --color seems to match the implementation. I think it would also be helpful to say something about what -f is intended to be used for and why the option character 'f' (force) is selected for that. My best guess is that it is intended to make the operation as efficient as possible, disabling time consuming operation such as sorting the list and stat()ing all the entries, but I really don't know the background. Regards, /Niels ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils