Greg,
Am 25.01.2016 um 19:52 schrieb Greg Wooledge:
> On Mon, Jan 25, 2016 at 07:09:27PM +0100, Reuti wrote:
>> Sometimes I miss a feature in Bash to get access to the plain command line
>> the user typed, including all quotes and other redirections
>
> There is a way to do this, but it is not a
On Mon, Jan 25, 2016 at 07:09:27PM +0100, Reuti wrote:
> Sometimes I miss a feature in Bash to get access to the plain command line
> the user typed, including all quotes and other redirections
There is a way to do this, but it is not a path for the sane.
http://www.chiark.greenend.org.uk/~sgtath
Hi,
> Am 19.01.2016 um 17:49 schrieb Greg Wooledge :
>
> On Tue, Jan 19, 2016 at 11:39:07AM -0500, Adam Danischewski wrote:
>> Bash also removes the single quotes before it hits read when the single
>> quotes are attached to the delimiter option (-d'').
>
> And in EVERY OTHER COMMAND. This is h
On Tue, Jan 19, 2016 at 12:09:54PM -0500, Adam Danischewski wrote:
> In the case for read -d'' very probably the user has attempted to supply
> the null delimiter, but read quietly takes the next argument. I think it
> makes sense to bump empty strings away from the option when they occur
> after o
Right, the programs don't see those empty strings because the shell is
stripping them when it parses the line. But for options, for the shell
parser to strip away the empty string presumes that the user made a mistake
and has needlessly/erroneously provided a useless empty string.
In the case for
On Tue, Jan 19, 2016 at 11:39:07AM -0500, Adam Danischewski wrote:
> Bash also removes the single quotes before it hits read when the single
> quotes are attached to the delimiter option (-d'').
And in EVERY OTHER COMMAND. This is how quotes work. This is utterly
fundamental to bash and the enti
> > Other shells must go out of their way to suppress it, then.
>
> Most of the other shells remove NUL bytes from `read's input. They
> probably do this before checking the delimiter.
Bash also removes the single quotes before it hits read when the single
quotes are attached to the delimiter op
2016-01-18 11:25:49 -0500, Greg Wooledge:
[...]
> Other shells must go out of their way to suppress it, then.
>
> wooledg@wooledg:~$ while IFS= read -r -d '' foo; do echo "<$foo>"; done <
> <(printf 'one\0two\0')
>
>
> wooledg@wooledg:~$ ksh
> $ while IFS= read -r -d '' foo; do echo "<$foo>"; d
2016-01-18 11:16:06 -0500, Chet Ramey:
[...]
> > But it's
> > an incredibly useful feature, and has been used in countless real
> > life scripts. At this point, while it is still undocumented, it is
> > nevertheless a feature whose omission would be considered a regression.
>
> It's not a special
On 1/18/16 11:25 AM, Greg Wooledge wrote:
> On Mon, Jan 18, 2016 at 11:16:06AM -0500, Chet Ramey wrote:
>> On 1/18/16 8:14 AM, Greg Wooledge wrote:
>>> I suspect the interpretation of -d '' to mean a NUL byte delimiter
>>> may have been an accident originally (but that's a guess).
>>
>> I guess tha
On Mon, Jan 18, 2016 at 11:16:06AM -0500, Chet Ramey wrote:
> On 1/18/16 8:14 AM, Greg Wooledge wrote:
> > I suspect the interpretation of -d '' to mean a NUL byte delimiter
> > may have been an accident originally (but that's a guess).
>
> I guess that depends on what you mean by `accident'.
Hap
On 1/18/16 8:14 AM, Greg Wooledge wrote:
> On Sat, Jan 16, 2016 at 02:28:27PM -0500, Adam Danischewski wrote:
>> If it is expected behavior I didn't see it in the documents.
>
> I suspect the interpretation of -d '' to mean a NUL byte delimiter
> may have been an accident originally (but that's a
On Sat, Jan 16, 2016 at 02:28:27PM -0500, Adam Danischewski wrote:
> If it is expected behavior I didn't see it in the documents.
I suspect the interpretation of -d '' to mean a NUL byte delimiter
may have been an accident originally (but that's a guess). But it's
an incredibly useful feature, an
Adam Danischewski schreef op 16-01-16 om 20:28:
> Yet if we look for the null byte:
bash, like most UNIX shells, cannot store or handle null bytes. (zsh is
the only exception I know of.)
> $> while IFS= read -r -d'' a; do echo "got $a"; done < <(find . -type f
> -print0)
> *
hi,
On Sat, Jan 16, 2016 at 8:28 PM, Adam Danischewski
wrote:
> ..
> Yet if we look for the null byte:
> $> while IFS= read -r -d'' a; do echo "got $a"; done < <(find . -type f
> -print0)
>returns nothing
this is because it is the same as:
read -r -d a;
I think there
It seems the parameter for the delimiter for the read built-in behaves
differently for the NULL case, and it is a very useful case. I found this
after a difficult to track down bug appeared in some of my code, so I
thought I would pass it on to you.
If it is expected behavior I didn't see it in t
16 matches
Mail list logo
