bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ls display directory context?


From: Nic Ferrier
Subject: Re: ls display directory context?
Date: Thu, 20 Jan 2005 14:13:25 +0000

address@hidden (James Youngman) 
 writes:

> On Thu, Jan 20, 2005 at 12:57:39AM +0000, Nic Ferrier wrote:
>
>> Is there any reason (apart from POSIX compliance) why ls cannot output
>> file lists with the directory context attached to the file?
>> 
>> For example:
>> 
>>   $ cd somedir
>>   $ ls --with-dir-ctx childdir 
>>   childdir/in.txt childdir/my.txt childdir/craft.txt
>> 
>> This simple feature would replace a lot of complex find invocations
>> for me.
>
> What sort of find invocation?   Something like just
>
>       find childdir | xargs 
>
> perhaps?   Or if you need to know more about the files,
>
>       find childdir -maxdepth 1 -ls 

I sense a certain disdain for my suggestion.

Let me try and prove that it is not frivolous.

Specifically, what I want to do is get a date ordered list of a
directory in order to build a large XML file from the contents of the
files.

My non-ls to achieve it is this:

   find childdir -type f -printf "%AY%Am%Ad%AH%AM %p\n" |\
         sort -r | gawk '{print $2}' 

I could possibly do this:

   find childdir -type f | xargs ls

but that would be relying on xargs/ls being able to handle that number of
args on it's command line.


I'm lucky that in this instance there is no directory structure
(except CVS) under childdir (and never will be). If there were my find
would get even more complicated:

   find childdir --max-depth=1 -type f \
           -printf "%AY%Am%Ad%AH%AM %p\n" |\
           sort -r | gawk '{print $2}' 

But if ls had a switch --dircontext then the correct result could be
achieved like this:

  ls -t -I CVS --dircontext childdir

This is significant because this snippet is going to go into a
Makefile. Using the find makes life very difficult, I have to have a
whole new target for building a temporary filelist because otherwise
the cat command is so complicated:

   index.filelist:
        find xnicsblog/xml -type f -not -name "*.~*" \
                -printf "%AY%Am%Ad%AH%AM %p\n" |\
                sort -r | gawk '{print $$2}' > $@


But if I had a --dircontext switch on ls I could do it easily with one
command:

  ls -t -I CVS --dircontext childdir | xargs -1 cat 

My XML producing Makefile target would then look like this:

  index.html:
      ( ls -t -I CVS --dircontext childdir | xargs cat ) |\
            xsltproc  x.xslt - > $@

Which is a lot simpler than the two targets I have now. It is also
*considerably* fewer command invocations for something apparently
uncomplex.



This is not an isolated incident. Over the last 3 years, when I've
been doing a lot of work with content management systems  built with
simple shell tools, I've found that I often wanted ls to report the
dircontext (mainly in scenarios just like the one above).


I've considered the semantics of the --dircontext switch. I think what
I actually want is ls to be able to acknowledge what directory I told
is to look in.

So if I say:

   ls --dircontext childdir

it comes back with:

   childdir/a.txt childdir/b.txt

etc...

But if I say:

   ls --dircontext ../mydir/childdir

then I think it should come back with:

   ../mydir/childdir/a.txt ../mydir/childdir/b.txt


I realise that this is not what ls is for. And if ls does this maybe
find's utility is depleted. But it seems such a small change to
functionality for such a big win.


So what do you think?

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]