[Toybox] tar tests.

[scsijon]

Dumb Question, but,

And if the filename was a link?

Sorry Rob..., hopefully your seeing where i'm coming from as i'm not 
sure I can explain it further without a lot of waffle.

regards
scsijon

On 21/03/19 07:14, toybox-request at lists.landley.net wrote:

> Message: 1
> Date: Wed, 20 Mar 2019 10:23:07 -0500
> From: Rob Landley <rob at landley.net>
> To: toybox <toybox at lists.landley.net>
> Subject: Re: [Toybox] tar tests.
> Message-ID: <4a92a86b-d875-8d23-c67e-29f2dae81229 at landley.net>
> Content-Type: text/plain; charset=utf-8
> 
> On 3/19/19 2:39 PM, Rob Landley wrote:
>> So what it's doing is filling out 6 digits (with zero padding on the left if
>> it's short!) and then sticking a space in the last byte.
>>
>> *shrug* I can do that. It's silly, but I can do it.
> 
> getline() gives me the newline at the end of the tar pattern name as part of the
> stream, so if I feed the array of command line arguments _and_ the do_lines()
> strings into the same function, you won't be able to specify a filename with a
> trailing \n on the command line.
> 
> I think that's ok because the shell is already trimming those? (Even echo
> "$(echo -e 'hello\n\n\n\n\n')" will trim _all_ the trailing \n off an argument
> because shell.) but it's a limitation I'm not entirely comfortable with, _and_
> it means that exec("tar") has the same limit the shell does. (The two characters
> you _can't_ have in a filename are / and NUL, you can totally have \n in a
> filename including at the end. And this is why we have wildcards for rm...)
> 
> Hmmm...
> 
> Rob
>