Re: feature request: -0 option for tr

[Craig Sanders]

On Sat, Jun 27, 2009 at 09:26:17PM -0600, Eric Blake wrote:
> According to Craig Sanders on 6/27/2009 7:20 PM:
> > please add a -0 option to tr, which is equivalent to
> > running:
> > 
> >     tr '\n' '\000'
> 
> Why should we burn an option letter, when it is not that much more typing
> to get what you wanted anyways?  

because it's a PITA to have to remember and type "tr '\n' '\000'" every
single time when 'tr -0' would be easier, and mnemonic. transforming
newline separated input into null separated input is such an extremely
common use-case that a convenience feature to support it is worthwhile.

and it's not like option letters are in short supply for tr. tr
currently only uses four (plus the usual --version, --help etc).


> An option letter makes the most sense only when there is no other easy
> way to do the same task.

GNU grep has -z and -Z options - by your reasoning above, these
convenience options are completely unecessary because you can easily
run "tr '\0' '\n'" before grep and "tr '\n' '\0'" after grep. the same
can be said of GNU sort's -z option. and tr itself is pointless because
you can do everything it does with sed. and grep can be seen as just a
convenience subset of either sed or awk for wusses who don't want to
type long command lines. and both of them are mere conveniences for
people who don't want to write their own C program...which is again a
convenience for people who don't want to write assembler.


> > this is a useful command for converting \n-terminated input lines to
> > null-terminated strings suitable for feeding into 'xargs -0' as many
> > programs can not generate null-terminated ouput by themselves.
> 
> This proposal doesn't really buy you anything.  

actually, it does. it buys you a standard, consistent, and documented
way of transforming newline-separated input into null-separated
output for feeding into xargs -0 (or any other program which can use
null-separated input).

it also buys you that feature on every system that has GNU coreutils
installed without having to write a trivial print0 shell-script on each
system.

> Either the output is already nul-terminated (in which case you don't
> need an extra tr process in the mix), or it is newline terminated (in
> which case you should just use plain xargs instead of 'xargs -0',

or it is newline-separated because one or more of the commands in the
pipeline you've constructed don't handle null-terminated input but the
final result may have spaces or other problematic chars in the filenames
so needs to be fed into xargs with -0.

there are dozens (hundreds!) of tools which can be used to
create/transform lists of filenames etc(*) which can not handle
null-terminated input or produce null-terminated output. using tr as the
final stage of the pipeline before feeding it into xargs -0 makes it
possible to use all of them without hassle or complication.


(*) not just filenames. can also be used for other types of arguments,
such as package names for dpkg or apt-get or rpm etc.


> and you already have to worry about the potential for filenames with
> embedded newlines).

filenames with embedded newlines are an extremely rare pathological case
beyond the scope of this request.

spaces and quote characters and even backslashes in filenames are far
more common, especially on systems were files are uploaded by users from
non-unix systems (e.g. ftp upload to web servers, samba file servers,
etc)


> In short, throwing tr in the mix just to convert newlines to nul bytes
> does not buy you any security.

who said anything about security?

the feature request was for convenience in performing a very common
task, not for security.

> But there is no need to change tr, when you can easily do this
> yourself:
> 
> $ cat <<\EOF >>/usr/local/bin/print0
> #!/bin/sh
> exec tr '\n' '\0'
> EOF
> $ chmod +x /usr/local/bin/print0

yes, i've already written variations of that script. in fact, i've
written it hundreds of times over the years because i've needed it on
hundreds of different systems.

i'm just sick and tired of having to write it again and again (or scp it
from somewhere else) when it's something that should be standard.  so
i submitted a feature request.

it's also irksome that a shell interpreter has to be involved.


craig

-- 
craig sanders <address@hidden>