[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: read Built-in Parameter Behavior -- Null Byte Delimiter

From: Adam Danischewski
Subject: Re: read Built-in Parameter Behavior -- Null Byte Delimiter
Date: Tue, 19 Jan 2016 11:39:07 -0500

> 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 option (-d'').  

I know its possible to not think of it as a bug, but it can cause very difficult to find errors because the other behavior -- putting the quoted argument next to the option -- works when the option value is not null -- a null delimiter option for read is common and useful -- so I think it's something worth addressing.

Perhaps it would be possible to put a filter on the Bash interpreter to check for the case of empty single quotes next to an option and handle it separately as special case?

E.g. my.bsh

echo "$#"
while getopts d: OPTION "$@"; do
 case "$OPTION" in
     echo "the optarg is ${OPTARG##*=}, optind is ${OPTIND}"
     [[ -z "${OPTARG}" ]] && echo "Let's set the null byte as the delim."
exit 0

$> ./my.bsh -d'' arg1 
## Incorrectly interprets arg1 as the option argument.
the optarg is arg1, optind is 3

## If Bash instead would do something like this to preserve the presence of the null argument I think it would alleviate a potential source of bugs:

$> eval $(echo "./my.bsh -d'' arg1" | sed "s/-d''/-d ''/g")
the optarg is , optind is 3
Let's set the null byte as the delim.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]