Re: ls --group-directories-first -U
[EMAIL PROTECTED] wrote:
J Would you *please* consider sending a precise suggestion
Sorry. OK, To both
man page:
--group-directories-first
group directories before files
And info page:
`--group-directories-first'
Group all the directories before the files and then sort the
directories and the files separately using the selected sort key
(see -sort option). That is, this option specifies a primary sort
key, and the -sort option specifies a secondary key.
please add:
Doesn't work if -U or -f are present.
Thanks.
How about the following patch?
I didn't mention -f, since that option is documented to
enable --sort=none (-U) semantics. I see that you've noticed
--group-directories-first is trumped by --sort=none even when --sort=none
comes first.
Unfortunately, --group-directories-first is a bit of a mess. Back when
that option was added, I knew that ls should have gained a new method for
specifying multiple sort keys. Then this option could have been added
as something like --sort=directories-first, and a secondary key would
have been specified via --yet-another-option=SECONDARY_SORT_KEY_TYPE.
But ls was already hairy in that area, too big, and with too many options, etc.
All that to say that I was tempted to change --group-directories-first,
but continue to resist :)
ls: Improve description of --group-directories-first.
* src/ls.c (usage) [--group-directories-first]: Improve description.
* doc/coreutils.texi (Which files are listed): Likewise.
Suggestion from Dan Jacobson.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index dfab040..fbab0b5 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -5894,6 +5894,8 @@ directories and the files separately using the selected
sort key
(see --sort option).
That is, this option specifies a primary sort key,
and the --sort option specifies a secondary key.
+However, any use of @option{--sort=none}
+(@option{-U}) disables this option altogether.
@item --hide=PATTERN
@opindex [EMAIL PROTECTED]
diff --git a/src/ls.c b/src/ls.c
index 46713f2..e0646ef 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -4386,7 +4386,9 @@ Mandatory arguments to long options are mandatory for
short options too.\n\
), stdout);
fputs (_(\
--group-directories-first\n\
- group directories before files\n\
+ group directories before files.\n\
+ disable with --sort=none (-U);\n\
+ augment with any other --sort option\n\
), stdout);
fputs (_(\
-G, --no-group in a long listing, don't print group names\n\
--
1.5.4.1.98.gf3293
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Day wrote: Yes, Bob. This problem came out because I set an alias for `ls' in my .bashrc file alias ls='ls -F --color' So when I run the script what goes in to the [] test is `ls -F --color -A ./dir' in fact. Thus issued the problem. Thanks for your msg. Hmm... But aliases are not used in scripts. Scripts shouldn't be reading your .bashrc file and therefore shouldn't be affected by aliases there. If in your environment scripts are reading you .bashrc file then you should fix it because there will almost certainly be other similar problems such as this. Are you setting ENV or BASH_ENV to your .bashrc environment file? That would cause scripts to source it. Although BASH_ENV and ENV have special uses they shouldn't be set in the normal course of events for bash. (For ksh use setting ENV is typical.) If that is the problem I think you should unset those variables. Or perhaps you are using the alias in your .bashrc file itself? Because aliases would only be expanded within the particular shell that source the .bashrc file. So if in the .bashrc script itself you were subsequently using the ls command after the alias then that would also be a problem. I usually put aliases at the very bottom of the file for this reason. In any case, you can avoid alias expansion by quoting the command. 'ls' ls \ls command ls All of those would avoid the alias expansion. Plus using --color=auto would also avoid the problem. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re:Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Bob Proulx [EMAIL PROTECTED] wrote： How did you happen to run into using 'ls --color' in a test such as this? That seems an unfortunate option choice there. I recommend not using --color there. But obviously you already thought of that and so I have to ask what you were doing that caused it to be there? Why not simply avoid saying anything there? Why not simply use 'ls' without color? Could you say a few more words about how you came about this problem? Yes, Bob. This problem came out because I set an alias for `ls' in my .bashrc file alias ls='ls -F --color' So when I run the script what goes in to the [] test is `ls -F --color -A ./dir' in fact. Thus issued the problem. Thanks for your msg. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls --group-directories-first -U
Hi Jim, have you ever consider my follow-up patch to patch#3596 with the name: ls_--group-directories-first_symlinks_to_dir_are_dirs_too.patch? Thanks. Bert ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls --group-directories-first -U
JM +(@option{-U}) disables this option altogether.
Looks good.
JM + disable with --sort=none (-U);\n\
Looks bad. One thinks disable by not using it in the first place.
Just word it like the first one above.
Yes the options are so complicated that one needs a n-to-the-nth-power
grid chart to sort out all their interactions... so one can only make
observations.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Eric Blake wrote: It may be worth considering a patch to coreutils, such that plain --color implies --color=auto rather than --color=always. For example, this would match how 'git config' reacts when interpreting color options (where 'auto' and 'true' are synonyms, and 'always' must be explicit). FWIW, I commonly use --color to turn color back on. My usage: I list a directory and it scrolls off screen. So I redo it with |more appended -- and then I get unhappy because I don't get the same output I just looked at now that I've added a paging option, so when color is helping sort out what is what, I re-edit again to: ls --color|more... (my more is aliased to less, FYI). Having to specify --color=always...well that's just more torture -- I have --color=auto in my LS_OPTIONS...(or the alias, forget which sometimes...). That's the only time I really want color no matter what the output, which is why I specify color=auto. I or perhaps someone else might find it disconcerting to type: ls --color|more and get no color -- what's the point of specifying --color on the command line if it doesn't turn on color? -l ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bert Wesarg on 2/12/2008 9:50 AM: | Thanks for the patch, but a change in behavior like that | requires some serious justification. | I read the thread in the mail archive. Eric Blake questioned the symlink | behavior in the first reply (still in the patch tracker): I'm not sure if the current state of things is more from Francesco's code or mine, but I do remember the conversation: | | Your patch does not take into account what behavior should be used | with symlinks to dirs - are they grouped with directories, or with | files, or does it depend on other options (such as -L)? | | And indeed a -L with --group-directories-first does sort symlinks to | directories like directories. But they don't look like symlinks anymore. | | Anyway, this fact was not really discussed, Francesco decided that | symlinks to directories are non-directories and no one objected. Additionally, IIRC, one of the reasons that --group-directories-first was added was to mimic default behavior of a certain 'dir' program popular on proprietary systems, but those systems did not have symlinks, so there really is no prior art on how ls should behave on symlinks-to-dirs. | | Currently there is no test for this option, even Francesco has posted | one which also consider symlinks, and the documentation for this options | doesn't mention symlinks too. So, IMHO there is no change in documented | behavior with this patch. This point I can agree with. --group-directories-first is relatively new, and since it is currently silent about behavior on links, I have no problem with changing that behavior; however, I would insist that if we make a change, we add test cases and documentation to lock in that behavior for the future. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHskaa84KuGfSFAYARAqbqAKClDoy+4iLwce0cRZEq4hiCuzeJ8gCfb/EG rSOmEJ1fl7+zVyjJ9DDQ2Sk= =PtGu -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
Eric Blake wrote: Additionally, IIRC, one of the reasons that --group-directories-first was added was to mimic default behavior of a certain 'dir' program popular on proprietary systems, but those systems did not have symlinks, so there really is no prior art on how ls should behave on symlinks-to-dirs. This is not exactly true. When running under said Proprietary-OS, directories are grouped first, but .lnk files -- which are explorer's idea of links are grouped with files. I don't know if I agree with explorers choice, however, since when I've created a symlink to a directory, I'd 'like' to see it with the directories, as I would want to treat it as a directory, for visual scanning purposes. Additionally, on explorer, a visual cue of a little arrow in the lower left of the icon is usually visible. In *nix, though, with classifier-suffixes on, a normal ls will show a @ at the end of a symlink, even though that symlink might point to an executable that would normally be tagged with a *. Thus, to be consistent, are you wanting to look at the type of what the symlink points to (-L), or the directory entry itself (which would be a symlink). To have symlinks-to-dirs be treated as dirs (in absence of -L, but then not have other files be classified as their underlying type, seems inconsistent). | Currently there is no test for this option, even Francesco has posted | one which also consider symlinks, and the documentation for this options | doesn't mention symlinks too. So, IMHO there is no change in documented | behavior with this patch. It would be inconsistent with the proprietary OS's behavior after which the option was modeled. Is that logical? Believe me, I understand wanting to see symlinks to dirs grouped with dirs, but this isn't how it's done in explorer and doesn't seem consistent. I wouldn't mind a treat-symlinks-to-dirs-as-dirs type option, but that seems awfully esoteric. Why should symlinks to dirs be treated differently from symlinks to non-dirs? If I use classifier suffixes (as my aliases always enable), then how would a symlink-dir be flagged? dir/ or dir@? HEY---*light-bulb*. You can have two types of links to directories and I don't know if there is any behavioral difference, BUT...it seems I am able to have: ln -s dir/ symdir and ln -s dir symdir Perhaps it would be logical (if anyone think I'm daft, I'm sure they'll speak up)...to group symlinks to names that end in / be grouped with dirs, while symlinks to names w/o / are treated same as now...? It's slightly obscure, but a rational for the difference in behavior could be logically made? (or am I delusional?) A possible slight gotcha...with the embedded / at the end to indicate a dir, then the classifier char creates a double //. Not a major problem in my opinion, but it can look odd: ish:/tmp ln -s /tmp foo ish:/tmp ln -s /tmp/ foo2 ish:/tmp ll foo* lrwxrwxrwx 1 4 2008-02-12 18:08 foo - /tmp/ lrwxrwxrwx 1 5 2008-02-12 18:09 foo2 - /tmp// ish:/tmp ls foo* foo@ foo2@ -- -Linda ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Wrong behavior of ``readlink -f''?
Hello! I'm a bit stumped with this behavior of ``readlink -f'', as it doesn't match what I had expected. #v+ [EMAIL PROTECTED]:~/tmp $ mkdir a-long [EMAIL PROTECTED]:~/tmp $ touch a-long/f [EMAIL PROTECTED]:~/tmp $ ln -s a-long a [EMAIL PROTECTED]:~/tmp $ readlink -f a/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a-long/../a/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a/../a-long/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a/../a/f [EMAIL PROTECTED]:~/tmp $ echo $? 1 #v- Why doesn't it resolve the latter case just as the previous ones? Because there are two symbolic links involved? Or two times the same one? Strange. #v+ [EMAIL PROTECTED]:~/tmp $ readlink --version | head -n 2 readlink (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. [EMAIL PROTECTED]:~/tmp $ apt-cache policy coreutils | grep Installed Installed: 5.97-5.3ubuntu3 #v- I even decided to give the git master branch an try, but: ``configure.ac:35: require Automake 1.10.1, but have 1.10''. There I decided to stop and not begin upgrading my whole toolchain. Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cut: invalid option -- [BLANKS]
$ cut -s' ' cut: invalid option -- Try `cut --help' for more information. What do you mean, ? I typed an -s. Give a proper error message. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC]: --format=FORMAT option for ls
Jim Meyering wrote on 12-02-08 15:50: Pádraig Brady [EMAIL PROTECTED] wrote: I can't think of any reason I would use `ls --format` over `find -printf` Ha! Good point. Nor can I. I'll remove the TODO item. Actually, from the perspective of modularity that is (justifiably) hammered on so often, wouldn't a format/printf option have been somewhat more at home with 'ls' than with 'find'? bjd ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 2/12/2008 11:30 AM: | | Here's the result I'll push in a day or two: What about the corresponding patch to dircolors? I haven't done that yet. Would you like to do it? FYI, this time, I'm adding a dist check to ensure the sets of 2-letter codes in dircolors.c and ls.c are equal. It'll look something like this: dc=$(sed -n '/static.*ls_codes\[/,/};'/p src/dircolors.c \ |sed -n '/^ */p'|tr , '\n'|sed 's/^ *//' \ |sed -n 's/^\(..\)/\1/p'|sort -u) ls=$(sed -n '/static.*indicator_name\[/,/};'/p src/ls.c \ |sed -n '/^ */p'|tr , '\n'|sed 's/^ *//' \ |sed -n 's/^\(..\)/\1/p'|sort -u) test $dc = $ls || exit 1 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/12/2008 11:30 AM: | | Here's the result I'll push in a day or two: | | ls --color no longer outputs unnecessary escape sequences | In --color mode, plain files do not get any color, not even white. | When no highlighting is required, ls outputs no escape sequence at all. | (indicator_no) [C_RESET]: New enum value. | (indicator_name) [rs]: Corresponding new string. | (color_indicator): Make the 'normal' and 'file' markers be NULL. | Use rs (C_RESET) to reset to ordinary colors. What about the corresponding patch to dircolors? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsfex84KuGfSFAYARAleWAJ4vLiypc9IzO0hKhGQskqqHMdC7eACfUHV4 4o2rdm84ikMOi3gyenQ7o7w= =iy2I -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Jim Meyering [EMAIL PROTECTED] wrote: Here's the result I'll push in a day or two: ls --color no longer outputs unnecessary escape sequences BTW, that patch reduces by up to about 60% the size of the output of ls -C --color=always when there are many short-named files, e.g., as you'd see in an mh-style mailbox dir. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
Jim Meyering wrote: Bert Wesarg [EMAIL PROTECTED] wrote: With the --group-directories-first option, ls shows directories on top of all non directory entries, but IMHO symlinks to directories should be handle as directories as well. Thanks for the patch, but a change in behavior like that requires some serious justification. I read the thread in the mail archive. Eric Blake questioned the symlink behavior in the first reply (still in the patch tracker): Your patch does not take into account what behavior should be used with symlinks to dirs - are they grouped with directories, or with files, or does it depend on other options (such as -L)? And indeed a -L with --group-directories-first does sort symlinks to directories like directories. But they don't look like symlinks anymore. Anyway, this fact was not really discussed, Francesco decided that symlinks to directories are non-directories and no one objected. Currently there is no test for this option, even Francesco has posted one which also consider symlinks, and the documentation for this options doesn't mention symlinks too. So, IMHO there is no change in documented behavior with this patch. Therefor I change this to an RFC, to further discuss this question. Regards Bert ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug] coreutils 5.2.1 - incorrect behaviour for mv --reply=no
When using the option --reply=no for mv, it still overwrites the file when it is not supposed to. Here is a quick demo: [EMAIL PROTECTED] ~]# mkdir mvtest [EMAIL PROTECTED] ~]# cd mvtest/ [EMAIL PROTECTED] mvtest]# mkdir moveto [EMAIL PROTECTED] mvtest]# echo test file.ext [EMAIL PROTECTED] mvtest]# touch moveto/file.ext [EMAIL PROTECTED] mvtest]# ls file.ext moveto [EMAIL PROTECTED] mvtest]# mv --reply=no -v file.ext moveto/ `file.ext' - `moveto/file.ext' [EMAIL PROTECTED] mvtest]# ls moveto [EMAIL PROTECTED] mvtest]# This is wrong as the destination file should not be overwritten when using --reply=no Oher relevant information: [EMAIL PROTECTED] ~]# mv --version mv (coreutils) 5.2.1 Written by Mike Parker, David MacKenzie, and Jim Meyering. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] ~]# rpm --query coreutils coreutils-5.2.1-31.7 [EMAIL PROTECTED] ~]# rpm --query glibc glibc-2.3.4-2.39 [EMAIL PROTECTED] ~]# uname -a Linux wilber.pointclark.net 2.6.18-8.1.14.3.cccustom #1 PREEMPT Sun Nov 4 22:53:10 EST 2007 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] ~]# ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC]: --format=FORMAT option for ls
On Feb 12, 2008 1:22 PM, Jim Meyering [EMAIL PROTECTED] wrote: Steven Schubiger [EMAIL PROTECTED] wrote: I hacked up a prototype of ls with the possibility of specifying a format string that currently solely defines the order of items. Thanks for working on this. However, before you invest more time in it, please look at how GNU find handles its -printf predicate and see if it is feasible to share parts of that code. If this functionality is useful to coreutils, I'm happy to refactor the findutils code so that it's reusable. However, there are a small number of format directives that don't seem to be usefully sharable. For example, %d, %P, and %H. The existing find code is also running out of format specifiers; I've been considering a keyword-oriented variant like %(hardlinkcount)d for a while. That at least would be a little more extensible. On the other hand, refactoring the code would probably only be worthwhile if the result would not be reused. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC]: --format=FORMAT option for ls
Pádraig Brady [EMAIL PROTECTED] wrote: I can't think of any reason I would use `ls --format` over `find -printf` Ha! Good point. Nor can I. I'll remove the TODO item. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC]: --format=FORMAT option for ls
Steven Schubiger [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] wrote: However, before you invest more time in it, please look at how GNU find handles its -printf predicate and see if it is feasible to share parts of that code. As far as I can tell, most of the logic boils down to insert_fprintf() in findutils' parser.c. Concerning the feasibility of sharing parts, I don't know offhand (it doesn't look easy though). Albeit I searched through the coreutils mailing list archive and found some according threads regarding extending ls, I'm not exactly sure what format functionality is needed (unless we want a working find -printf resembling behavior). If you're going to implement it, then you should propose what you think is right. IMHO, that would include most if not all of what find's printf predicate does. Then there'd have to be a few new format specifiers so that in the end we can say that by default, ls acts as if it had been given the --format=... option. Of course, implementing such a feature properly will not be quick or easy. If it were so easy, it would have been done long ago. Don't underestimate the value of reusing find's code. Not only do you get stable and well-tested code, but you get the well-written documentation that goes with it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC]: --format=FORMAT option for ls
Jim Meyering [EMAIL PROTECTED] wrote: However, before you invest more time in it, please look at how GNU find handles its -printf predicate and see if it is feasible to share parts of that code. As far as I can tell, most of the logic boils down to insert_fprintf() in findutils' parser.c. Concerning the feasibility of sharing parts, I don't know offhand (it doesn't look easy though). Albeit I searched through the coreutils mailing list archive and found some according threads regarding extending ls, I'm not exactly sure what format functionality is needed (unless we want a working find -printf resembling behavior). Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Eric Blake [EMAIL PROTECTED] wrote: According to Day on 2/11/2008 8:35 PM: | | [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty | | the echoed message is always Not Empty, regardless of the fact that ./dir is actually EMPTY. Below is the tested result. Thanks for the report. However, this is not necessarily a bug. By itself, --color is documented to mean --color=always, in which case ls outputs command sequences to initialize and restore colors back to normal: $ ls -A --color | od -tx1z 000 1b 5b 30 6d 1b 5b 6d .[0m.[m 007 And since that is output (even though it does not show up on the terminal), the string is non-empty, hence the result of the [] test. You really want the color output to be supressed in this context (in $() command substitution, the output is not a terminal, so color escape sequences don't normally make sense to the downstream client), so you should consider using --color=auto instead: $ ls -A --color=auto | od -tx1z 000 It may be worth considering a patch to coreutils, such that plain --color implies --color=auto rather than --color=always. For example, this would match how 'git config' reacts when interpreting color options (where 'auto' and 'true' are synonyms, and 'always' must be explicit). Sounds ok. Any other opinions? It may also be worth a patch to ls to omit color sequences altogether if there is no other output, although this may be more difficult to code and/or justify. Yes, that is worthwhile. Ed Avis wrote a patch to do just that a few years ago. It was held up due to copyright assignment processing delays, and then I forgot about it. I've just dug up the patch, merged it, and added one more test along with the usual administrivia. Here's the result I'll push in a day or two: ls --color no longer outputs unnecessary escape sequences In --color mode, plain files do not get any color, not even white. When no highlighting is required, ls outputs no escape sequence at all. * src/ls.c (print_with_color): (used_color): New global. (indicator_no) [C_RESET]: New enum value. (indicator_name) [rs]: Corresponding new string. (color_indicator): Make the 'normal' and 'file' markers be NULL. Use rs (C_RESET) to reset to ordinary colors. (process_signals): Restore default colors only if necessary. (main): Don't call prep_non_filename_text here. (print_name_with_quoting): Call it here, instead. (prep_non_filename_text): Use C_RESET, not C_NORM. (print_color_indicator): Return bool, not void. Print nothing, when possible. (put_indicator): Call prep_non_filename_text the first time. * tests/misc/ls-misc: Test for above. * tests/ls/color-dtype-dir: Adapt: no escapes around regular file name. * TODO: Remove item. * NEWS: Mention this. Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- NEWS |4 +++ TODO |3 -- src/ls.c | 60 +- tests/ls/color-dtype-dir |4 +- tests/misc/ls-misc | 17 ++-- 5 files changed, 63 insertions(+), 25 deletions(-) diff --git a/NEWS b/NEWS index e05e1c3..b9f25e6 100644 --- a/NEWS +++ b/NEWS @@ -10,6 +10,10 @@ GNU coreutils NEWS-*- outline -*- rmdir --ignore-fail-on-non-empty detects and ignores the failure in more cases when a directory is empty. +** Improvements + + ls --color no longer outputs unnecessary escape sequences + ** Consistency mkdir and split now write --verbose output to stdout, not stderr. diff --git a/TODO b/TODO index 3cec054..f8cc66a 100644 --- a/TODO +++ b/TODO @@ -133,9 +133,6 @@ Changes expected to go in, someday. Pending copyright papers: - ls --color: Ed Avis' patch to suppress escape sequences for -non-highlighted files - getpwnam from Bruce Korb pb (progress bar) from Miika Pekkarinen diff --git a/src/ls.c b/src/ls.c index 46713f2..bf94e8f 100644 --- a/src/ls.c +++ b/src/ls.c @@ -207,7 +207,7 @@ static bool file_ignored (char const *name); static uintmax_t gobble_file (char const *name, enum filetype type, ino_t inode, bool command_line_arg, char const *dirname); -static void print_color_indicator (const char *name, mode_t mode, int linkok, +static bool print_color_indicator (const char *name, mode_t mode, int linkok, bool stat_ok, enum filetype type); static void put_indicator (const struct bin_str *ind); static void add_ignore_pattern (const char *pattern); @@ -489,6 +489,12 @@ ARGMATCH_VERIFY (indicator_style_args, indicator_style_types); static bool print_with_color; +/* Whether we used any colors in the output so far. If so, we will + need to restore the default color
Re: [RFC]: --format=FORMAT option for ls
On Feb 12, 2008 2:59 PM, James Youngman [EMAIL PROTECTED] wrote: On the other hand, refactoring the code would probably only be worthwhile if the result would not be reused. Obviously the not there should be removed. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
Bert Wesarg [EMAIL PROTECTED] wrote: With the --group-directories-first option, ls shows directories on top of all non directory entries, but IMHO symlinks to directories should be handle as directories as well. Thanks for the patch, but a change in behavior like that requires some serious justification. It'd be slightly easier if you were proposing a new option, but, for ls, even that is problematic, since there are already so many. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] ls --group-directories-first: symlinks to dirs are dirs too
With the --group-directories-first option, ls shows directories on top of all
non directory entries, but IMHO symlinks to directories should be handle as
directories as well.
Regards.
Bert
2008-02-12 Bert Wesarg [EMAIL PROTECTED]
ls --group-directories-first: symlinks to dirs are dirs too.
src/ls.c (is_symlink_to_directory): New function.
(DIRFIRST_CHECK): Use it.
---
src/ls.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --quilt old/src/ls.c new/src/ls.c
--- old/src/ls.c
+++ new/src/ls.c
@@ -2849,10 +2849,21 @@ static bool
is_directory (const struct fileinfo *f)
{
return f-filetype == directory || f-filetype == arg_directory;
}
+/* Return true if F is a symlink that refers to a directory. */
+static bool
+is_symlink_to_directory (const struct fileinfo *f)
+{
+ return (f-filetype == symbolic_link
+ f-linkname
+ f-linkok
+ f-stat_ok
+ S_ISDIR (f-linkmode));
+}
+
/* Put the name of the file that FILENAME is a symbolic link to
into the LINKNAME field of `f'. COMMAND_LINE_ARG indicates whether
FILENAME is a command-line argument. */
static void
@@ -2992,12 +3003,14 @@ typedef int (*qsortFunc)(V a, V b);
The do { ... } while(0) makes it possible to use the macro more like
a statement, without violating C89 rules: */
#define DIRFIRST_CHECK(a, b)\
do\
{ \
- bool a_is_dir = is_directory ((struct fileinfo const *) a); \
- bool b_is_dir = is_directory ((struct fileinfo const *) b); \
+ bool a_is_dir = is_directory ((struct fileinfo const *) a) \
+ || is_symlink_to_directory ((struct fileinfo const *) a); \
+ bool b_is_dir = is_directory ((struct fileinfo const *) b) \
+ || is_symlink_to_directory ((struct fileinfo const *) b); \
if (a_is_dir !b_is_dir)\
return -1; /* a goes before b */\
if (!a_is_dir b_is_dir)\
return 1; /* b goes before a */\
} \
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC]: --format=FORMAT option for ls
Steven Schubiger [EMAIL PROTECTED] wrote: I hacked up a prototype of ls with the possibility of specifying a format string that currently solely defines the order of items. Thanks for working on this. However, before you invest more time in it, please look at how GNU find handles its -printf predicate and see if it is feasible to share parts of that code. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[RFC]: --format=FORMAT option for ls
I hacked up a prototype of ls with the possibility of specifying
a format string that currently solely defines the order of items.
I had to change quite a bit of the underlying code to make it work,
as in, moving most of the routines called by print_long_format() to
functions, that are both used by the user-defined and default format
code. Right now only a column is buffered at once (the majority is '\0'
terminated) and then written by DIRED_FPUTS(). It probably would be
better to buffer the entire row and have it then printed to the output
stream (as it mostly was before).
How it works:
/your/custom/ls --printf=%M %O %G %S %T %f -l
should be roughly equivalent to a bare
/bin/ls -l
I've chosen --printf, because it was easier to add and I didn't want
to possibly pollute the --format code (at least not, for now).
The patch is not complete at all, but merely an approximation.
Ideas, opinions and critique are welcome.
Steven Schubiger
diff --git a/src/ls.c b/src/ls.c
index 46713f2..b15042b 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -584,6 +584,12 @@ static bool immediate_dirs;
static bool directories_first;
+static bool print_formatted_line;
+
+#define FORMAT_TYPES_NUM 10
+
+static char format_specifier[FORMAT_TYPES_NUM];
+
/* Which files to ignore. */
static enum
@@ -765,6 +771,7 @@ static struct option const long_options[] =
{indicator-style, required_argument, NULL, INDICATOR_STYLE_OPTION},
{dereference, no_argument, NULL, 'L'},
{literal, no_argument, NULL, 'N'},
+ {printf, required_argument, NULL, 'P'},
{quote-name, no_argument, NULL, 'Q'},
{quoting-style, required_argument, NULL, QUOTING_STYLE_OPTION},
{recursive, no_argument, NULL, 'R'},
@@ -1368,6 +1375,79 @@ main (int argc, char **argv)
exit (exit_status);
}
+static void
+extract_formatstring_specifiers (const char *fmt)
+{
+ const char *fmt_start;
+ int cnt, i = 0;
+
+ if (!strlen (fmt))
+error (EXIT_FAILURE, 0, _(format string must not be empty));
+
+ fmt_start = fmt;
+
+ while (*fmt) {
+cnt = 0;
+while (cnt 2) {
+ switch (cnt)
+{
+ case 0:
+if (*fmt != '%')
+ error (EXIT_FAILURE, 0, _(format specifier must begin with %%));
+ break;
+ case 1:
+if (isalpha(*fmt))
+ {
+char ch;
+ch = *fmt;
+if (i = FORMAT_TYPES_NUM)
+ goto end;
+if (ch == 'f' (fmt - fmt_start != strlen (fmt_start) - 1))
+ error (EXIT_FAILURE, 0, _(file format specifier %%f must be
at end));
+if (islower(ch) (ch != 'f' ch != 's'))
+ format_specifier[i] = toupper(ch);
+else
+ format_specifier[i] = ch;
+i++;
+ }
+else
+ error (EXIT_FAILURE, 0, _(format character must be a valid
character));
+break;
+ /* never reached */
+ default:
+ abort ();
+}
+ cnt++;
+ fmt++;
+}
+while (*fmt == ' ')
+ fmt++;
+ }
+
+ end:
+
+ for (i = 0; isalpha(format_specifier[i]); i++)
+{
+ switch (format_specifier[i])
+{
+ case 'f':
+ case 's':
+ case 'A':
+ case 'B':
+ case 'G':
+ case 'I':
+ case 'M':
+ case 'O':
+ case 'S':
+ case 'T':
+break;
+ default:
+error (EXIT_FAILURE, 0, _(format specifier %%%c is unsupported),
format_specifier[i]);
+break;
+}
+}
+}
+
/* Set all the option flags according to the switches specified.
Return the index of the first non-option argument. */
@@ -1508,7 +1588,7 @@ decode_switches (int argc, char **argv)
{
int oi = -1;
int c = getopt_long (argc, argv,
- abcdfghiklmnopqrstuvw:xABCDFGHI:LNQRST:UXZ1,
+ abcdfghiklmnopqrstuvw:xABCDFGHI:LNPQRST:UXZ1,
long_options, oi);
if (c == -1)
break;
@@ -1675,6 +1755,11 @@ decode_switches (int argc, char **argv)
set_quoting_style (NULL, literal_quoting_style);
break;
+case 'P':
+ print_formatted_line = true;
+ extract_formatstring_specifiers (optarg);
+ break;
+
case 'Q':
set_quoting_style (NULL, c_quoting_style);
break;
@@ -3345,20 +3430,25 @@ get_current_time (void)
/* Print the user or group name NAME, with numeric id ID, using a
print width of WIDTH columns. */
-static void
-format_user_or_group (char const *name, unsigned long int id, int width)
+static char *
+format_user_or_group (char *p, char *name, unsigned long int id, int width)
{
size_t len;
+ char *iter;
if (name)
{
int width_gap = width - mbswidth (name, 0);
int pad = MAX (0, width_gap);
- fputs (name, stdout);
+
+ iter = name;
+ while
Re: Wrong behavior of ``readlink -f''?
Thomas Schwinge [EMAIL PROTECTED] wrote: $ readlink -f a/../a/f $ echo $? 1 ... readlink (GNU coreutils) 5.97 Why doesn't it resolve the latter case just as the previous ones? Because there are two symbolic links involved? Or two times the same one? Strange. Thanks for the report. That's because the code concluded it had encountered a cycle. The bug was fixed for coreutils-6.9.90 via a change to gnulib's canonicalize module. Regarding your attempt to build from checked-out sources, you might want to try the latest stable release: http://article.gmane.org/gmane.comp.gnu.core-utils.announce/44 ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.10.tar.gz ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.10.tar.lzma or a snapshot (post-6.10) tarball: http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/12611 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
