Re: No such device or address when opening /dev/fd/ on opened /dev/tcp socket

On 4/5/21 3:14 PM, Oğuz wrote: 5 Nisan 2021 Pazartesi tarihinde Chet Ramey > yazdı: There's no guarantee that file descriptors opened with socket(2) show up in /dev/fd. Bash doesn't emulate /dev/fd if the system provides it, so it's up to the OS on those

Re: No such device or address when opening /dev/fd/ on opened /dev/tcp socket

5 Nisan 2021 Pazartesi tarihinde Oğuz yazdı: > 5 Nisan 2021 Pazartesi tarihinde Chet Ramey yazdı: > >> On 4/5/21 3:14 PM, Oğuz wrote: >> >>> 5 Nisan 2021 Pazartesi tarihinde Chet Ramey >> > yazdı: >>> >>> There's no guarantee that file descriptors opened with

Empty array referenced by indirection reports unbound variable

set -u array=() __ref=array[@] : "${array[@]}" # Reports nothing : "${!__ref}" # Unbound variable Using bash version 5.1.4. I know this can be avoided by using namerefs instead but indirection is more portable when no assignment is needed and this sometimes allows my portable functions to have

Re: select syntax violates the POLA

On 4/1/21 5:40 PM, Greywolf wrote: Or do you mean my coding style (which has been valid for over 25 years)? Hey, if you want to go there, `select' has been in bash with its current syntax for longer than that. ;-) (A month over 27 years, if you're curious.) -- ``The lyf so short, the

Re: select syntax violates the POLA

On 4/1/21 5:54 PM, Greywolf wrote: On 4/1/2021 8:57, Chet Ramey wrote: It's more like `select' doesn't inherit some of the shell's special cases.     select dir in ${d[@]}; do {     break;     } done; ...but select breaks on the "} done;" syntax Yes, you need a list

No such device or address when opening /dev/fd/ on opened /dev/tcp socket

5 Nisan 2021 Pazartesi tarihinde Chet Ramey yazdı: > > There's no guarantee that file descriptors opened with socket(2) show up in > /dev/fd. Bash doesn't emulate /dev/fd if the system provides it, so it's up > to the OS on those systems whether they do or not. > > It doesn't generate that error

Re: Changing the way bash expands associative array subscripts

On Mon, Apr 5, 2021 at 9:44 PM Chet Ramey wrote: > > On 4/1/21 3:02 PM, konsolebox wrote: > > >> To do what, exactly? > > > > To keep this working in both behaviors. > > > > declare -A a > > key='$(echo foo)' > > a[$key]=1 > > unset 'a["$key"]' > > declare -p a # declare -A a=() > > I suppose.

Re: No such device or address when opening /dev/fd/ on opened /dev/tcp socket

On Tue, Apr 6, 2021 at 3:38 AM Oğuz wrote: >> Yeah. If you have /dev/fd though you have /dev/fd/1 (and even /dev/stdout), >> so OP could have done `echo a | tee /dev/fd/1 >/dev/tcp/host/port' instead > > > That should have been `echo a | tee /dev/fd/3 3>&1 >/dev/tcp/host/port' Nice strategies.

Re: No such device or address when opening /dev/fd/ on opened /dev/tcp socket

On Tue, Apr 6, 2021 at 2:46 AM Chet Ramey wrote: > There's no guarantee that file descriptors opened with socket(2) show up in > /dev/fd. Bash doesn't emulate /dev/fd if the system provides it, so it's up > to the OS on those systems whether they do or not. > > It doesn't generate that error on

Re: No such device or address when opening /dev/fd/ on opened /dev/tcp socket

5 Nisan 2021 Pazartesi tarihinde Chet Ramey yazdı: > On 4/5/21 3:14 PM, Oğuz wrote: > >> 5 Nisan 2021 Pazartesi tarihinde Chet Ramey > chet.ra...@case.edu>> yazdı: >> >> There's no guarantee that file descriptors opened with socket(2) show >> up in >> /dev/fd. Bash doesn't emulate

Re: SIGCHLD traps shouldn't recurse

On 2021/04/03 00:41, Oğuz wrote: but I don't think it's useful at all because the number of pending traps keeps piling up, and there is no way to reset that number. If there is no real use case for recursive SIGCHLD traps (which I can't think of any), I think this should change; no SIGCHLD trap

Re: No such device or address when opening /dev/fd/ on opened /dev/tcp socket

On 4/5/21 1:31 PM, konsolebox wrote: Not sure if this is a bug or a limitation but this works: # echo a | ( exec {fd}>/path/to/regular/file; tee /dev/fd/"$fd" ) While this produces a "No such device or address" error: # echo a | ( exec {fd}>/dev/tcp/host/port; tee /dev/fd/"$fd" ) There's no

Re: select syntax violates the POLA

On 4/5/2021 6:27, Chet Ramey wrote: On 4/5/21 5:06 AM, Greywolf wrote: but if you want to go down that track, it's kind of interesting to note that {} on a single line demands a ; before the }, while () prohibits it. This isn't true: $ ./bash -c '(echo a b c;)' a b c but it is the case

Re: select syntax violates the POLA

On 4/1/21 9:23 PM, Dale R. Worley wrote: Greg Wooledge writes: It's amazing how many people manage to post their code with NO comments or explanations of what it's supposed to do, what assumptions are being made about the inputs, etc. This leaves us to guess. It seems to be a modern style.

Re: zsh style associative array assignment bug

On Mon, Mar 29, 2021 at 4:18 PM Chet Ramey wrote: > If you look at > > a=( k1 v1 k2 v2 k3 v3) > > as more or less syntactic sugar for > > a=( [k1]=v1 [k2]=v2 [k3]=v3 ) > > it's reasonable that > > a=( k1 v1 k2 ) > > is equivalent to > > a=( [k1]=v1 [k2]= ). And that's what bash does. This

Re: Changing the way bash expands associative array subscripts

On 4/1/21 3:02 PM, konsolebox wrote: To do what, exactly? To keep this working in both behaviors. declare -A a key='$(echo foo)' a[$key]=1 unset 'a["$key"]' declare -p a # declare -A a=() I suppose. You'll be able to set compatibility levels to make this work without resorting to wrappers.

Re: select syntax violates the POLA

On 4/5/21 5:06 AM, Greywolf wrote: the same level of egregious brokenness as select. Good god, take a breath. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu

No such device or address when opening /dev/fd/ on opened /dev/tcp socket

Not sure if this is a bug or a limitation but this works: # echo a | ( exec {fd}>/path/to/regular/file; tee /dev/fd/"$fd" ) While this produces a "No such device or address" error: # echo a | ( exec {fd}>/dev/tcp/host/port; tee /dev/fd/"$fd" ) Simpler forms like this does the same: # echo a |

Re: zsh style associative array assignment bug

5 Nisan 2021 Pazartesi tarihinde Jesse Hathaway yazdı: > This equivalence, though it is reasonable, creates a special case for the > last > value in an array which imposes a greater cognitive burden on the > programmer. > The programmer needs to be aware that omitting the last value will create

Re: Changing the way bash expands associative array subscripts

On 3/30/21 7:05 PM, konsolebox wrote: As I've observed, in single expansion mode, unset will fail to unset a value when the key has a closing bracket in it. Perhaps unset should check the last character first when looking for the closing bracket. Tested in 5.1.4. There is some support for

Re: select syntax violates the POLA

On 4/5/21 5:06 AM, Greywolf wrote: but if you want to go down that track, it's kind of interesting to note that {} on a single line demands a ; before the }, while () prohibits it. This isn't true: $ ./bash -c '(echo a b c;)' a b c but it is the case that } is a reserved word, while ) is

Re: select syntax violates the POLA

On 4/5/2021 14:21, Chet Ramey wrote: This presented an opportunity to marginally simplify the grammar, so it's a win all around. The change will be in the next devel branch push. You have my sincere gratitude. I did not expect so much to come of it. Chet

Re: select syntax violates the POLA

On 4/5/2021 13:52, Chet Ramey wrote: On 4/1/21 5:40 PM, Greywolf wrote: Or do you mean my coding style (which has been valid for over 25 years)? Hey, if you want to go there, `select' has been in  bash with its current syntax for longer than that. ;-) (A month over 27 years, if you're

Re: select syntax violates the POLA

On Sat, Apr 3, 2021 at 1:09 AM Robert Elz wrote: > | [[ ]] and (( )) are a form of reserved words themselves > > Those are bash specials, and I am fairly sure that (( and )) will be > operators, not reserved words (they cannot really be the latter, as ( and > ) are operators) and I suspect

Re: select syntax violates the POLA

5 Nisan 2021 Pazartesi tarihinde konsolebox yazdı: > > The manual itself may be lacking in some places but the syntax here is > explicit. There's no reason to follow otherwise. These "other methods" > can only be an implementation mistake or a compromise that's not > exactly a supported

Re: Changing the way bash expands associative array subscripts

2021年3月30日(火) 0:03 Chet Ramey : > On 3/15/21 9:41 PM, Koichi Murase wrote: > > Can you also take care of the behavior of `unset -v 'a[@]''? > > Well, you have to pick one behavior or another. The `@' subscript always > expands to all members of the array. The current behavior is consistent > with

Re: select syntax violates the POLA

On 4/1/2021 8:57, Chet Ramey wrote: Yes, you need a list terminator so that `done' is recognized as a reserved word here. `;' is sufficient. Select doesn't allow the `done' unless it's in a command position. Some of the other compound commands have special cases, mostly inherited from the Bourne

Re: select syntax violates the POLA

On 4/2/2021 8:21, konsolebox wrote: That's not a rule but a special compromise. [[ ]] and (( )) are a form of reserved words themselves just like () and {} as they can be used multi-line but they aren't allowed to be adjacent to else et al without a semicolon. [[ ]], (( )), {}, and () are

Re: select syntax violates the POLA

On 4/4/2021 23:13, konsolebox wrote: On Sat, Apr 3, 2021 at 1:09 AM Robert Elz wrote: | [[ ]] and (( )) are a form of reserved words themselves Those are bash specials, and I am fairly sure that (( and )) will be operators, not reserved words (they cannot really be the latter, as ( and )