while loops can not read "\"
Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux kali 5.7.0-kali1-amd64 #1 SMP Debian 5.7.6-1kali2 (2020-07-01) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 0 Release Status: release command line: cat poc.txt | while read i; do echo $i;done it can not read "\" but for loops can read: for i in $(cat ~/poc.txt);do echo $i;done \ \ \ \ \ hello world
Re: While and for loops can read all filename when poc.txt have "*"
On Tue, Dec 22, 2020 at 03:42:46PM +0800, ffvh gfff wrote: > for i in $(cat ~/poc.txt);do echo $i;done https://mywiki.wooledge.org/DontReadLinesWithFor https://mywiki.wooledge.org/BashFAQ/001 https://mywiki.wooledge.org/BashPitfalls$pf1
Re: while loops can not read "\"
On 22/12/2020 08:18, ffvh gfff wrote:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux kali 5.7.0-kali1-amd64 #1 SMP Debian 5.7.6-1kali2
(2020-07-01) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 0
Release Status: release
command line:
cat poc.txt | while read i; do echo $i;do
In fact, the read builtin can read backslashes. It's just that you
didn't escape them. Use the -r option.
$ help read | grep -- -r
-rdo not allow backslashes to escape any characters
$ echo '\' | { read i; echo "$i"; }
$ echo '\' | { read -r i; echo "$i"; }
\
--
Kerin Millar
Re: While and for loops can read all filename when poc.txt have "*"
(With apologies to the poster as I accidentally commented off-list ...) On 22/12/2020 07:42, ffvh gfff wrote: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall > uname output: Linux kali 5.7.0-kali1-amd64 #1 SMP Debian 5.7.6-1kali2 > (2020-07-01) x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.1 > Patch Level: 0 > Release Status: release > > command line: > cat poc.txt | while read i; do echo $i;done You didn't quote the expansion of $i. Therefore, the results of the expansion are subject to word splitting, with each resulting word being subject to pathname expansion. See https://github.com/koalaman/shellcheck/wiki/SC2086. > > and > > for i in $(cat ~/poc.txt);do echo $i;done > > poc.txt have "*" ,then above loops will read all ~/ filename. > Also i submit report through 'bashbug' , here is for the working POC. As before, only this time the results of your command substitution are also subject to word splitting and pathname expansion. See https://mywiki.wooledge.org/BashPitfalls#pf1. Neither case demonstrates a bug. -- Kerin Millar
Re: while loops can not read "\"
On Tue, Dec 22, 2020 at 04:18:39PM +0800, ffvh gfff wrote: > command line: > cat poc.txt | while read i; do echo $i;done > it can not read "\" You forgot to use the -r option in your read command.
Re: while loops can not read "\"
Arguably it's a bug that 'help read' doesn't mention the effect of
backslashes, other than what can be extrapolated from the description of
-r. It only says "The line is split into fields _as with word splitting_",
but word splitting doesn't recognize backslashes as special. It should not
be necessary to read the description of all options to infer the behaviour
of a command as used without them.
The online reference is clearer on this:
https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html#index-read
On Tue, Dec 22, 2020 at 4:05 PM wrote:
> On 22/12/2020 08:18, ffvh gfff wrote:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
> > -Werror=format-security -Wall
> > uname output: Linux kali 5.7.0-kali1-amd64 #1 SMP Debian 5.7.6-1kali2
> > (2020-07-01) x86_64 GNU/Linux
> > Machine Type: x86_64-pc-linux-gnu
> >
> > Bash Version: 5.1
> > Patch Level: 0
> > Release Status: release
> >
> > command line:
> > cat poc.txt | while read i; do echo $i;do
> In fact, the read builtin can read backslashes. It's just that you
> didn't escape them. Use the -r option.
>
> $ help read | grep -- -r
>-r do not allow backslashes to escape any characters
>
> $ echo '\' | { read i; echo "$i"; }
>
> $ echo '\' | { read -r i; echo "$i"; }
> \
>
> --
> Kerin Millar
>
>
Re: inconsistent readonly error behavior
I don't understand what distinction you're trying to make; any example you
can give?
I added an extra near-copy of the script to the gist replacing the
assignment with unset (
https://gist.github.com/abathur/8d18853e06f2a8cf3a97e45acda17f68#file-unset-sh-console),
and corresponding output where you can see that it hits all of the lines
skipped in the assignment example. (The behavior in this example is in line
with what I see by replacing the assignment with other errors like a
missing command, or a ${parameter:?word} expansion.)
On Mon, Dec 21, 2020 at 11:46 PM Oğuz wrote:
> On Tue, Dec 22, 2020 at 7:28 AM Travis Everett
> wrote:
>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64OS: darwin17.7.0
>> Compiler: clang
>> Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
>> uname output: Darwin ecf1160e 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug
>> 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64
>> Machine Type: x86_64-apple-darwin17.7.0
>> Bash Version: 5.
>> 0Patch Level: 18
>> Release Status: release
>>
>> Description:
>> While trying to intentionally trap/ignore EXIT in a sourced script, I
>> noticed that I couldn't keep it from exiting when it tried to overwrite
>> PATH, which I had set to readonly. When I tried to minimize the repro
>> case,
>> I realized the behavior seems to differ between simple command and command
>> list contexts.
>>
>> Repeat-By:
>>
>> readonly sigh=1
>>
>> sigh=2
>> : reached
>>
>> sigh=2a; : skipped
>> sigh=2b || : skipped
>>
>> if true; then
>> sigh=3
>> : skipped
>> fi
>
>
> I don't understand what is wrong here. Is there any shell that doesn't
> discard the current line or the lines that constitute a compound command
> when a shell error occurs?
>
>
>> I also have a gist with a slightly longer example (and output from
>> bash, bash-sh, and osh:
>> https://gist.github.com/abathur/8d18853e06f2a8cf3a97e45acda17f68
>>
>> T
>>
>
Re: inconsistent readonly error behavior
22 Aralık 2020 Salı tarihinde Travis Everett
yazdı:
> I don't understand what distinction you're trying to make; any example you
> can give?
>
> I added an extra near-copy of the script to the gist replacing the
> assignment with unset (https://gist.github.com/abathur/
> 8d18853e06f2a8cf3a97e45acda17f68#file-unset-sh-console), and
> corresponding output where you can see that it hits all of the lines
> skipped in the assignment example. (The behavior in this example is in line
> with what I see by replacing the assignment with other errors like a
> missing command, or a ${parameter:?word} expansion.)
>
I wouldn't expect `unset' to have that effect either. That an error that
can be detected during parse discards the entire input line or the
surrounding compound command makes sense though. I don't think a change is
needed, it wouldn't make sense to me if these two printed `reached`, and
the third printed `b=2'.
if true; then
: ${x!y}
echo reached
fi
set -u
if true; then
: ${x}
echo reached
fi
readonly a=1
b=1
if true; then
(( a += 1, b += 1 ))
echo b=$b
fi
--
Oğuz
