Re: [coreutils] basename/dirname can't handle stdin?

[Pádraig Brady]

On 13/01/11 23:15, Jeff Blaine wrote:
> So then, please review.  One question at the bottom.
> 
> # Most basic usage
> basename /foo/bar.txt                               => bar.txt
> 
> 
> # Old/current "basename NAME SUFFIX" compat-
> # ibility
> basename /foo/bar.txt .txt                          => bar
> 
> 
> # ERROR, one too many operands
> basename /foo/bar.txt /x.txt /y.txt                 => ERROR
> 
> 
> # BSD-adopted flag to signify no args are a
> # suffix, process all
> basename -a /foo/bar.txt /x/y.txt                   => bar.txt
>                                                        y.txt
> 
> 
> # For completeness, showing 3 args with -a
> basename -a /foo/bar.txt /x/y.txt /a/b.txt          => bar.txt
>                                                        y.txt
>                                                        b.txt
> 
> 
> basename -s .txt -a /foo/bar.txt /x/y.txt /a/b.txt  => bar
>                                                        y
>                                                        b
> 
> 
> # No args means read stdin (-f,--filter mode)
> cat filelist.txt | basename                         => bar.txt
>                                                        y.txt
>                                                        b.txt
> 
> 
> # Only "-s <arg>" means read stdin (-f,--filter
> # mode)
> cat filelist.txt | basename -s .txt                 => bar
>                                                        y
>                                                        b
> 
> 
> # Handle NUL-terminated stdin
> find / -print | basename --file0-from=-             => bar.txt
>                                                        y.txt
>                                                        b.txt
> 
> 
> # Handle NUL-terminated stdin with suffix strip
> # (assuming /hh has our 3 files in it and is
> # readable)
> find /hh -print | basename --file0-from=- -s .txt   => bar
>                                                        y
>                                                        b
> 
> 
> # Handle NUL-terminated FILE input
> find / -print | basename --file0-from=FILE          => bar.txt
>                                                        y.txt
>                                                        b.txt
> 
> etc...
> 
> Is "-f,--filter" necessary?
> 
> 

It would be nice not to mandate it, but without it
a script containing the following for example could hang:

path=$(basename $path 2>/dev/null || echo default_path)

Perhaps we should only support --files0-from
and the normal filtering case can be handled with:

find / | xargs basename -a

In fact thinking more about it we might not need --files0-from either.
It's used in du,wc, and sort as they need to deal with all files
from a single process invocation (to generate totals etc.)
But that's not the case for basename.

So in summary, just implement -a and -s like BSD does?

cheers,
Pádraig.