Re: Documentation discrepancy for ls -f

2006-03-27 Thread Bob Proulx
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

2006-03-07 Thread Paul Eggert
[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

2006-03-03 Thread Niels Möller
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