What:
A new feature for the 'ls' program, initially designed to be triggered
by the (randomly picked) '-e' option, that shall enable the printing
of the absolute paths to the files listed, as opposed to the "filename
only" standard approach used today.
Why:
Well, I decided to write that because i was trying to filter/find
files based on the information that option '-l' can give by grep'ing
the results of a recursive ('-R') ls, and I couldn't accomplish this
satisfactorily because 'grep' would return me the relative names of
the files only (and so I couldn't just guess where they actually
were). But then I found out that, against my previous beliefs formed
by a misreading of the man pages, 'find' could do it with no hassle
and, therefore, my little "patch" almost became pointless.
But I decided to post it anyway because:
1) It still makes sense, in the case that the user decides to 'grep'
over the results of a recursive 'ls' (for whichever reason)
2) It might be useful for things I can't just think of
3) The final visual result is kind of pleasant, making it a somewhat
usable and desirable feature
As for the technical aspects, there goes the full commented 'diff' of
the source code against the CVS current version:
-- First of all, the declaration of the boolean value (global
variable) that shall indicate when the option was requested at
command-line.
446a447,450
> /* True means to display file's absolute name. -e */
>
> static bool print_absolute_name;
>
-- Then, we should obviously detect whenever it is requested and
change our global variable accordingly. (function: decode_switches())
1511a1516,1519
>
> case 'e':
> print_absolute_name = true;
> break;
-- The absolute name "computation" is taken out of a conditional code
block and put into the main flux of the function, so it can be reached
everytime. Plus, additional steps are taken to make sure it gets the
absolute path properly, including when no "target" is passed to 'ls'.
(function: gobble_file())
2520a2529,2547
> /* Absolute name of this file. */
> char *absolute_name;
>
> if (name[0] == '/')
> absolute_name = (char *) name;
> else
> {
> if ((dirname[0] == '.' && dirname[1] == '\0') ||
> (dirname[0] == 0))
> {
> char *current_working_dir = getenv("PWD");
> if (current_working_dir != NULL)
> dirname = current_working_dir;
> }
>
> absolute_name = alloca (strlen (name) + strlen (dirname) + 2);
> attach (absolute_name, dirname, name);
> }
>
-- Deletion of the old code block (the one inside the 'if'
conditional). (function: gobble_file())
2552,2554d2578
< /* Absolute name of this file. */
< char *absolute_name;
<
2557,2564d2580
< if (name[0] == '/' || dirname[0] == 0)
< absolute_name = (char *) name;
< else
< {
< absolute_name = alloca (strlen (name) + strlen (dirname) + 2);
< attach (absolute_name, dirname, name);
< }
<
-- If our feature was requested, then do it! (function: gobble_file())
2739c2755,2759
< f->name = xstrdup (name);
---
> if (print_absolute_name)
> f->name = xstrdup (absolute_name);
> else
> f->name = xstrdup (name);
>
-- C'mon! It surely deserves its own usage help description. (function: usage)
4154a4175
> -e display the absolute (full) path of each file\n\
As for the design flaws, the only one I couldn't think of was the
portability issue regarding the dependence on the "PWD" environment
variable (this is only used to get the absolute path for the current
working directory, not the subdirectories). However, as far as I know,
every shell implements/uses it, so it shouldn't be an issue. Anyhow,
as you can see in the code, additional measures were taken to assure
that, in case PWD is not set, absolute path should fall back to "."
(sounded reasonable for me).
Besides that, the program runs beautifully and, hopefully, free of
bugs (after all, this mailing list should solve bugs, not create
them). :D
Comment!
Cheers,
Julio Auto
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
