On 03/03/2012 07:58 PM, Jérémy Compostella wrote: >> On 03/03/2012 02:10 PM, Jérémy Compostella wrote: >>> All, >>> >>> I'm interesting in implementing these features: >>> >>> 1. basename BSD options and behavior compatibility: >>> >>> Add the following options: >>> -s, --suffix: specify the suffix >>> -a, --multiple: every argument is treated as a string as if basename >>> were invoked with just one argument. >> >> cool >> >>> Moreover: >>> - with more than two arguments basename acts as if -a was specified. >> >> That would introduce an inconsistency if basename was run with 2 filenames. >> So I think you must make -a explicit. > I agree it looks a bit inconsistent but it's part of the BSD > behavior. Without that we lose a part of the BSD behavior > compatibility. So, are you sure I should discard this behavior ?
I just logged onto an OS X box there and you're right: $ printf "%s\n" 1/1 2/2 | xargs basename 1 $ printf "%s\n" 1/1 2/2 3/3| xargs basename 1 2 3 However I think it's dangerous to do that. If I was writing a script I would probably test with 1 or 3 or more arguments. But the script would then fail if given 2 args based on transient conditions. I would not emulate that "feature". >>> - if -s is specified, act as if -a was specified too. >> >> yes. >> >>> >>> Arguments for this feature is convenience and BSD compatibility. Let me >>> know if this is sufficient to provide it in GNU/coreutils. >>> >>> 2. basesame acts as a filter: >>> >>> The http://lists.gnu.org/archive/html/coreutils/2011-01/msg00086.html >>> post convince me that maybe this feature is not relevant because there >>> are actually other very simple ways to achieve this. >>> >>> What do you think? >> >> Right. If basename is not taking from stding then >> it doesn't need the -z option to split on \0 I think, >> since xargs will do that for us: >> >> find | xargs -r0 basename -a > > Eric Blake said: >> It's been brought up before, and the consensus has always been that if >> someone would write the patches, it would be worthwhile. We do need >> support for a -0 or some other way to do NUL-terminated filtering, >> though. > which conflict with the idea that this feature is not really worth. I'm > a bit confused now ... Yes, I agreed with Eric that -0 was useful, but on consideration if not processing stdin, then I don't think it's of use. cheers, Pádraig.
