bug#14174: BUG REP: tee takes an annoyingly long time in some system.
tag 14174 + moreinfo close 14174 thanks On 04/10/2013 11:48 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote: Hello sir, Not sure if it is tee's problem. Tee works well in my workstation, but it will take a long time on cluster. See the example below. Could you if possible show me the reason why tee spends so long time while it is working on cluster? Thank you for the report. However, you can imagine that we have problems to reproduce this issue. First of all, what do you mean by is working on cluster? 2. With tee @ 1 minute 46 seconds: /home/sqdev16 time echo ' SET TRANSACTION ISOLATION LEVEL READ COMMITTED, READ WRITE, NO ROLLBACK OFF, MULTI COMMIT ON; DELETE WITH MULTI COMMIT FROM manageability.instance_repository.problem_instance_table WHERE (gen_ts_lct) ((CURRENT_TIMESTAMP) - CAST(CAST(0 AS INTEGER) AS INTERVAL HOUR(2))); ' | sqlci | tee -a junk --- SQL operation complete. + --- 0 row(s) deleted. End of MXCI Session real1m45.969s user0m0.180s sys 0m0.093s What's the output of sqlci? Can you redirect it to a file and use that as input for tee? Does that make a difference? ... | sqlci file cat file | time tee -a junk Can you provide strace output with timing information? ... | strace -tt tee -a junk Another possibility: writing to 'junk' may somehow be blocked during that run. Are there such timing difference between ... | sqlci /dev/null ... | sqlci junk2 # a new file / truncating ... | sqlci junk ... | sqlci /tmp/junk # i.e. a local file system ... | sqlci | tee /dev/null ... | sqlci | tee -a /tmp/junk # i.e. a local file system ? And finally, what version of tee are you using (tee --version)? Is it self-compiled or did it come with your distribution (which may have added patches on top of the upstream version)? Have a nice day, Berny
bug#14174: BUG REP: tee takes an annoyingly long time in some system.
Bringing back on list.
I didn't intend to take off list sorry.
Details below...
On 04/11/2013 06:57 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote:
On 04/10/2013 09:53 PM, Pádraig Brady wrote:
On 04/10/2013 10:48 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote:
Hello sir,
Not sure if it is tee's problem. Tee works well in my workstation, but it
will take a long time on cluster. See the example below. Could you if
possible show me the reason why tee spends so long time while it is
working on cluster?
This simple tests below illustrate how rep_age can take 30 times longer
than necessary:
1. Without tee @3 seconds
/home/sqdev16 time echo '
SET TRANSACTION ISOLATION LEVEL READ COMMITTED, READ WRITE, NO ROLLBACK
OFF, MULTI COMMIT ON;
DELETE WITH MULTI COMMIT FROM
manageability.instance_repository.problem_instance_table
WHERE (gen_ts_lct) ((CURRENT_TIMESTAMP) - CAST(CAST(0 AS INTEGER) AS
INTERVAL HOUR(2))); ' | sqlci
--- SQL operation complete.
+
--- 0 row(s) deleted.
End of MXCI Session
real0m3.354s
user0m0.184s
sys 0m0.099s
2. With tee @ 1 minute 46 seconds:
/home/sqdev16 time echo '
SET TRANSACTION ISOLATION LEVEL READ COMMITTED, READ WRITE, NO ROLLBACK
OFF, MULTI COMMIT ON;
DELETE WITH MULTI COMMIT FROM
manageability.instance_repository.problem_instance_table
WHERE (gen_ts_lct) ((CURRENT_TIMESTAMP) - CAST(CAST(0 AS INTEGER) AS
INTERVAL HOUR(2))); ' | sqlci | tee -a junk
--- SQL operation complete.
+
--- 0 row(s) deleted.
End of MXCI Session
real1m45.969s
user0m0.180s
sys 0m0.093s
So it's probably not tee's issue.
Tee has a simple main loop that synchronously reads stdin and writes to
files and stdout.
Now there is little data being generated there so it's unlikely a buffering
issue
(which you could solve by putting some async buffering util in the pipeline
before tee (like pv for example)).
It seems to me that access to the junk file is taking the time?
How long does it take for example if you just | sqlci junk
You could use strace to see where time time is spent: ... | sqlci | strace
-rT tee -a junk
Hello Pádraig,
I'd like to show you the result I test today. Please have a look. Thanks.
1.Directly save it to temp file
$ time echo 'SQL...;' | sqlcitemp
real0m3.344s
user0m0.159s
sys 0m0.087s
2.with tee again
$ time echo 'SQL...;' | sqlci | tee -a temp
--- SQL operation complete.
--- 1 row(s) deleted.
End of MXCI Session
real1m43.853s
user0m0.159s
sys 0m0.128s
3.with strace -o out -rT tee -a junk;cat out
0.58 open(temp, O_WRONLY|O_CREAT|O_APPEND, 0666) = 3 0.19
0.48 fstat(3, {st_mode=S_IFREG|0640, st_size=636, ...}) = 0
0.11
0.56 lseek(3, 636, SEEK_SET) = 636 0.10
0.47 read(0, Hewlett-Packard NonStop(TM) SQL/..., 8192) = 129
0.234176
0.234237 write(1, Hewlett-Packard NonStop(TM) SQL/..., 129) = 129
0.17
0.39 write(3, Hewlett-Packard NonStop(TM) SQL/..., 129) = 129
0.16
0.36 read(0, , 8192) = 4 0.492161
0.492338 write(1, , 4) = 4 0.53
0.000107 write(3, , 4) = 4 0.30
0.73 read(0, \n--- SQL operation complete.\n, 8192) = 31
0.001297
0.001338 write(1, \n--- SQL operation complete.\n, 31) = 31
0.13
0.38 write(3, \n--- SQL operation complete.\n, 31) = 31
0.12
0.35 read(0, \n--- 0 row(s) deleted.\n, 8192) = 23 19.722140
19.78 write(1, \n--- 0 row(s) deleted.\n, 23) = 23 0.30
0.80 write(3, \n--- 0 row(s) deleted.\n, 23) = 23 0.094912
0.095704 read(0, , 8192) = 2 0.15
0.59 write(1, , 2) = 2 0.18
0.49 write(3, , 2) = 2 0.114997
0.115062 read(0, \n\nEnd of MXCI Session\n\n, 8192) = 23 0.14
0.62 write(1, \n\nEnd of MXCI Session\n\n, 23) = 23 0.21
0.79 write(3, \n\nEnd of MXCI Session\n\n, 23) = 23 0.000144
0.000190 read(0, , 8192) = 0 104.552230
104.616062 close(3) = 0 0.82 spend a long
time in closing??
0.000178 close(0) = 0 0.17
0.69 close(1) = 0 0.17
0.59 close(2) = 0 0.16
0.035280 exit_group(0) = ?
It seems that close(3) will take a long time. Um..I can solve this problem by
using sqlci log instead. But if I could know the root cause why tee cannot
close fast on cluster, I would be grateful to you.
So tee is spending time in read() waiting for data from stdin,
and this doesn't happen when writing to file.
So I can only conclude that sqlci is doing something weird with pipes.
Is it messing with non blocking I/O, pipe capacity and timers?
I presume you've have the same issue with: ... sqlci | cat temp
thanks,
Pádraig.
bug#14024: Test failure in coreutils 8.13
Pádraig, The Gnu bug-coreutils Archives does not seem to have linked my reply message of April 10, 2013, and your reply as below, to our previous messages for bug#14024 on and before March 27, 2013. See my message of 27 March 2013 21:08:09 GMT (in archive as 17:08) for details about the file system. I have repeated the echo... sequence below (remember this is now 8.21 not 8.13 following your message of Fri, 22 March 2013 12:45:56 GMT and my response of Wed, 27 March 2013 11:47:30 GMT). echo test a /usr/local/bin/install -Cv -m0644 a b 'a' - 'b' /usr/local/bin/stat a b File: 'a' Size: 5 Blocks: 8 IO Block: 4096 regular file Device: e02h/234881026d Inode: 6260011 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 501/ellisnthomas) Gid: ( 80/ admin) Access: 2013-04-11 15:08:12.0 +0100 Modify: 2013-04-11 15:07:52.0 +0100 Change: 2013-04-11 15:07:52.0 +0100 Birth: 2013-04-11 15:07:52.0 +0100 File: 'b' Size: 5 Blocks: 8 IO Block: 4096 regular file Device: e02h/234881026d Inode: 6260013 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 501/ellisnthomas) Gid: ( 80/ admin) Access: 2013-04-11 15:08:12.0 +0100 Modify: 2013-04-11 15:08:12.0 +0100 Change: 2013-04-11 15:08:12.0 +0100 Birth: 2013-04-11 15:08:12.0 +0100 /usr/local/bin/install -Cv -m0644 a b removed 'b' 'a' - 'b' The result in my message of 27 March 2013 21:08:09 GMT used /usr/bin/ stat not /usr/local/bin/stat and there was no response to the second install. Hope this helps Ellis On 10 Apr 2013, at 22:50, Pádraig Brady wrote: Could you indicate the file system you're using, and give the output of: echo test a /usr/local/bin/install -Cv -m0644 a b /usr/local/bin/stat a b /usr/local/bin/install -Cv -m0644 a b thanks, Pádraig.
bug#14189: ls -d bug ??
To: The most gracious and brilliant authors of the ever useful ls command. (The title is quite heartfelt - no sarcasm intended). I have to wonder. I've been using *nix of various kinds for nigh unto 15 years. I ran into an issue today that I've seen many times, and it still irks me. I've simply never taken the time to write to anyone about it. I assumed someone would report it and it would be magically fixed in the next version, but it never seems to. I've also seen several people elude to the same problem in forums, etc. Once in a blue moon, a person would like to view the subdirectories of the directory you are in, without seeing all the various files. Since you can use the ls command to view the files and directories that are contained in your pwd, one would THINK the intuitive method would be to type ls -d. Interestingly, the MAN page seems to indicate that this is the way to go, however, regardless of what directory you are in, if you type ls -d you don't get the expected result, but rather you get: . Which is like ls is telling you, Yup, you are in a directory! Wull DUH, like I couldn't figure out that I was in a directory. If I wanted to get more info on that I'd type pwd ! tree -dx ALMOST gives you the desired outcome, except it includes all the subdirectories of the subdirectories. ls -d, I would think, would tell you the same data that ls would tell you, minus the individual files. (In other words - show all the data with a d in the permissions, but not show the ones that don't have a d in the permissions). I'm not afraid to admit I may be missing the whole point (pardon the pun). Is it me, or am I just not understanding the importance of the . , and how that . might change from one directory to another? WHY does ls -d just give me a dot? Is that dot supremely important? Is there some reason it can't give me what (it appears) the manual says (and what makes sense) it should? Ray Dall Radio Frequency Engineer Author: Electronics for Sound Engineers This email sent via a virus free Linux computer.
bug#14024: Test failure in coreutils 8.13
Ellis N. Thomas wrote: The Gnu bug-coreutils Archives does not seem to have linked my reply message of April 10, 2013, and your reply as below, to our previous messages for bug#14024 on and before March 27, 2013. The mailing list archive tracks messages on the mailing list. The BTS (bug tracking system) tracks messages to the bug log. And of course the BTS mail forwards to the mailing list. The mailing list archive only knows about your email. If your email doesn't reply to a message, has missing In-Reply-To: and no References: headers, then it isn't threaded. Some mailers always (nastily) break threads. Conversely if someone replies creating those headers but changes the Subject line then the message is threaded as per the headers. Also the mailing list archive is rotated every month. If a thread of discussion cross month boundaries then the thread will be split across the monthly archives. I think that is what you are seeing here. It is in a different month. The BTS log on the other hand is a continuous trail of messages that are sent to the bug log. These will be a duplicate of the messages to the mailing list but the archive is a separate one and it is bug ticket centric. All information about the bug is in the bug log. See my message of 27 March 2013 21:08:09 GMT (in archive as 17:08) for details about the file system. For referencing bug related items I suggest using the BTS archive. I believe you are refering to this message: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14024#26 And now that I have added this information it too will appear in the bug log. Bob
bug#14189: ls -d bug ??
Hello Ray, Others can provide more detailed information about the rational of the dot file, but regarding your questions: r...@electronicstheory.com wrote, On 04/11/2013 02:17 PM: Once in a blue moon, a person would like to view the subdirectories of the directory you are in, without seeing all the various files. find -type d will list all directories (but will do so recursively). find -maxdepth 1 -type d will list only directories immediately under your current directory. Since it's once in a blue moon (as you've said), I guess there's no short form for that. If you need the extended information that ls provides: find -maxdepth 1 -type d -print0 | xargs -0 ls -ld ... Interestingly, the MAN page seems to indicate that this is the way to go, however, regardless of what directory you are in, if you type ls -d One use-case for -d is to show the information about the directory, instead of the *content* of the directory. Compare: ls -l /etc vs.: ls -ld /etc HTH, -gordon
bug#14189: ls -d bug ??
tags 14189 + notabug close 14189 thanks http://www.gnu.org/software/coreutils/faq/#ls-_002dd-does-not-list-directories_0021 r...@electronicstheory.com wrote: Once in a blue moon, a person would like to view the subdirectories of the directory you are in, without seeing all the various files. Thank you for your report. However what you are reporting is due to a misunderstanding of the usage of the command. Since you can use the ls command to view the files and directories that are contained in your pwd, one would THINK the intuitive method would be to type ls -d. But that is not correct. And it isn't as documented. Interestingly, the MAN page seems to indicate that this is the way to go, You have fallen into a trap. The computer is executing a program and does *exactly* what it was programmed to do. The documentation is written to say exactly what the program does. But you are thinking like a human and making an interpretation and an extrapolation based upon what you *want* it to do. Those are different things. The GNU ls documentation says this: `-d' `--directory' List just the names of directories, as with other types of files, rather than listing their contents. Do not follow symbolic links listed on the command line unless the `--dereference-command-line' (`-H'), `--dereference' (`-L'), or `--dereference-command-line-symlink-to-dir' options are specified. The GNU ls man page says: -d, --directory list directory entries instead of contents, and do not dereference symbolic links The online standards documents say: http://pubs.opengroup.org/onlinepubs/009695399/utilities/ls.html -d Do not follow symbolic links named as operands unless the -H or -L options are specified. Do not treat directories differently than other types of files. The use of -d with -R produces unspecified results. Each and every one of those applies the -d option to the arguments of the ls command. But what are the arguments to ls? If you type in ls with an argument then there is no doubt. $ mkdir foodir $ touch foodir/foofile1 $ ls foodir foofile1 At that point there is no doubt. You are asking it to list foodir. Let's apply the -d option. $ ls -d foodir foodir The -d option clearly applies to foodir. Therefore it prevents it from listing the contents. It lists only the name of the directory. This is as documented for -d that it lists only names and using -d prevents it from listing the directory argument contents. But what happens if you don't give ls an option? What is the default argument to ls? The GNU ls documentation says: 10.1 `ls': List directory contents == The `ls' program lists information about files (of any type, including directories). Options and file arguments can be intermixed arbitrarily, as usual. For non-option command-line arguments that are directories, by default `ls' lists the contents of directories, not recursively, and omitting files with names beginning with `.'. For other non-option arguments, by default `ls' lists just the file name. If no non-option argument is specified, `ls' operates on the current directory, acting as if it had been invoked with a single argument of `.'. That last line says it. Let me repeat it for emphasis. If no non-option argument is specified, `ls' operates on the current directory, acting as if it had been invoked with a single argument of `.'. If no arguments are specified then ls lists '.' as if it had been invoked ls .. however, regardless of what directory you are in, if you type ls -d If you run ls -d then we know from the documentation that it is the same as saying ls -d . and that will simply list the name of it because the -d option says only list the names of directories. Therefore the expected behavior is that it must only list the name of the '.' directory. you don't get the expected result, but rather you get: . Unfortunately you had incorrect expectations! :-) Any other result would be a bug. I hope I have convinced you that that ls is doing the right thing here and behaving as documented even if it isn't doing what you want it to do. This is a common misunderstanding and is one of the FAQ entries. Please read the FAQ entry here: 17 ls -d does not list directories! http://www.gnu.org/software/coreutils/faq/#ls-_002dd-does-not-list-directories_0021 Wull DUH, like I couldn't figure out that I was in a directory. If I wanted to get more info on that I'd type pwd ! If you didn't want it to list only the name of the directory and not the contents then why did you use the -d option? Since -d specifically prevents it from listing the contents. ls -d, I would think, would tell you the same data that ls would tell you, minus the individual files. (In other words - show all the data with a d in the permissions, but not show the ones that don't have a d
bug#14189: ls -d bug ??
On 04/11/13 11:17, r...@electronicstheory.com wrote: Is there some reason it can't give me what (it appears) the manual says (and what makes sense) it should? Sounds like there's a bug in the manual; it shouldn't say that ls -d outputs only directories. Can you please mention the wording you're talking about? To get something like what you want, you can use this command: ls -d */ or maybe: ls -d */ .*/
bug#14189: ls -d bug ??
On 04/11/2013 03:13 PM, Bob Proulx wrote:
If you didn't want it to list only the name of the directory and not
the contents then why did you use the -d option? Since -d
specifically prevents it from listing the contents.
ls -d, I would think, would tell you the same data that ls would tell you,
minus
the individual files.
(In other words - show all the data with a d in the permissions, but not
show
the ones that don't have a d in the permissions).
Perhaps you want this?
$ ls -log | grep ^d
$ ls -log | grep -v ^d
Or one of these:
$ find . -maxdepth 1 -type d -ls
$ find . -maxdepth 1 -type d -exec ls -logd {} +
Or you could use this to approximate things:
$ ls -d */
the trailing slash forces the shell to filter out non-directories as
part of expanding the glob, and then list just the names instead of the
contents of all remaining directories. But as written that only lists
non-hidden directories. If you don't mind listing '.', you can get
closer with:
$ ls -d */ .*/
But for a full list of all subdirectory names excluding '.' and '..',
you need three globs; and either a shell option that suppresses a glob
that has no match, or ignoring the errors when ls tries to warn you when
a glob doesn't match:
Portable (but risks hiding errors):
$ ls -d */ .[!.]/ .??*/ 2/dev/null
bash-specific:
$ (shopt -s nullglob; ls -d */ .[!.]/ .??*/)
All the sudden, the 'find' alternative suddenly seems nicer :)
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
bug#14189: ls -d bug ??
On 04/11/2013 03:31 PM, Eric Blake wrote: But for a full list of all subdirectory names excluding '.' and '..', you need three globs; and either a shell option that suppresses a glob that has no match, or ignoring the errors when ls tries to warn you when a glob doesn't match: Portable (but risks hiding errors): $ ls -d */ .[!.]/ .??*/ 2/dev/null Be aware that this also runs the risk of generating too long of a command line if the globs expand to a lot of names; while find specifically avoids exceeding command line length limits. On the other hand, while ls defaults to sorting its output, find does not; so if you need sorted output, you have to start considering the use of non-POSIX extensions such as GNU find's -print0 and sort's -z to generate and sort the list with unambiguous terminators, if you are worried that any of the names found might contain a newline in the name. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#14024: Test failure in coreutils 8.13
On 04/11/2013 03:30 PM, Ellis N. Thomas wrote: Pádraig, The Gnu bug-coreutils Archives does not seem to have linked my reply message of April 10, 2013, and your reply as below, to our previous messages for bug#14024 on and before March 27, 2013. See my message of 27 March 2013 21:08:09 GMT (in archive as 17:08) for details about the file system. I have repeated the echo... sequence below (remember this is now 8.21 not 8.13 following your message of Fri, 22 March 2013 12:45:56 GMT and my response of Wed, 27 March 2013 11:47:30 GMT). echo test a /usr/local/bin/install -Cv -m0644 a b 'a' - 'b' /usr/local/bin/stat a b File: 'a' Size: 5 Blocks: 8 IO Block: 4096 regular file Device: e02h/234881026d Inode: 6260011 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 501/ellisnthomas) Gid: ( 80/ admin) Access: 2013-04-11 15:08:12.0 +0100 Modify: 2013-04-11 15:07:52.0 +0100 Change: 2013-04-11 15:07:52.0 +0100 Birth: 2013-04-11 15:07:52.0 +0100 File: 'b' Size: 5 Blocks: 8 IO Block: 4096 regular file Device: e02h/234881026d Inode: 6260013 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 501/ellisnthomas) Gid: ( 80/ admin) Access: 2013-04-11 15:08:12.0 +0100 Modify: 2013-04-11 15:08:12.0 +0100 Change: 2013-04-11 15:08:12.0 +0100 Birth: 2013-04-11 15:08:12.0 +0100 /usr/local/bin/install -Cv -m0644 a b removed 'b' 'a' - 'b' Great thanks. That shows that the gid of the files is 80, which I presume is separate to your gid. That can happen if you're in a dir hierarchy that's g+s to a group other than your own. Hmm I see the test already detects this case and skips the test with skip_if_setgid_(). Perhaps POSIX default ACLs or something are setting this admin group for you? Can you confirm that the dir isn't setgid by showing the output of: /usr/local/bin/stat . Can you display ACLs with `getfacl .` ? Anyway it highlights a shortcoming in the test, and a possible shortcoming in install(1) itself. So let's setup such a setgid directory for illustration: $ mkdir -m g+s ti cd ti $ chgrp wheel . $ touch a $ install -Cv -m0664 a b `a' - `b' $ ls -l total 0 -rw-rw-r--. 1 padraig wheel 0 Apr 12 02:08 a -rw-rw-r--. 1 padraig wheel 0 Apr 12 02:08 b So we see above that the files are the same, so shouldn't need a subsequent install, but: $ install -Cv -m0664 a b removed `b' `a' - `b' That's because install(1) sees that b does not have our gid and assumes that the gid of b would be set to our gid if we did install, and so does the redundant operation. However switching things around, illustrates a possible problem with this logic in install(1). If we set the dest file to our group id, then install(1) assumes that that's what would be used for the file and does nothing, when it probably should to ensure that the group is reset? $ chgrp $USER b $ install -Cv -m0664 a b $ ls -l total 0 -rw-rw-r--. 1 padraig wheel 0 Apr 12 02:08 a -rw-rw-r--. 1 padraig padraig 0 Apr 12 02:08 b Now install couldn't really infer all the combinations of auto metadata settings that might occur on file creation, so we should probably put a warning with --compare in the texinfo to say it makes assumptions about default users and permissions which may be incorect in the presence of POSIX default ACLs or setgid directories for example. thanks, Pádraig.
bug#14189: ls -d bug ??
Bob Proulx wrote: 10.1 `ls': List directory contents == The `ls' program lists information about files (of any type, including directories). Options and file arguments can be intermixed arbitrarily, as usual. For non-option command-line arguments that are directories, by default `ls' lists the contents of directories, not recursively, and omitting files with names beginning with `.'. For other non-option arguments, by default `ls' lists just the file name. If no non-option argument is specified, `ls' operates on the current directory, acting as if it had been invoked with a single argument of `.'. That does seem like it could use some improvement. It makes the mistake of burying the lead by putting that last sentence so far down. I like the BSD man page version much better. Is there a way we can simplify this but still keep it descriptive? The FreeBSD man page is much better for this description. How about this? (I will work it up into a texinfo patch afterward.) The `ls' program lists information about files. If the file being listed is a directory then the contents of the directory is listed. If no non-option command-line arguments are specified then 'ls' operates on the current directory, acting as if it had been invoked with a single argument of `.'. `ls' is the same as `ls .'. For each non-option command-line argument that is not a directory `ls' lists the file name. For each non-option command-line argument that is a directory `ls' lists the names of files in the directory. Files starting with a '.' are ignored and hidden. WDYT? `-d' `--directory' List just the names of directories, as with other types of files, rather than listing their contents. Do not follow symbolic links listed on the command line unless the `--dereference-command-line' (`-H'), `--dereference' (`-L'), or `--dereference-command-line-symlink-to-dir' options are specified. And then perhaps this following. Also the above does not describe the interaction with -R. Option 1: `-d' `--directory' Do not list the contents of directories. List only the name. Do not follow symbolic links unless the `--dereference-command-line' (`-H'), `--dereference' (`-L'), or `--dereference-command-line-symlink-to-dir' options are specified. Overrides `--recursive', (`-R'). Option 2 with much more description: `-d' `--directory' Do not list the contents of directories. List only the name. Without this option any non-option command-line arguments that are directories are treated specially and instead of the name the contents are listed. This option turns that behavior off and directories are only listed by name, the same as any non-directory file. This is most typically used with `-l' to list the information for the directory itself instead of its contents. Do not follow symbolic links unless the `--dereference-command-line' (`-H'), `--dereference' (`-L'), or `--dereference-command-line-symlink-to-dir' options are specified. Overrides `--recursive', (`-R'). I like the conciseness of the first. But the extra description in the second seems useful. WDYT? Bob
