Re: 'wait -n' with and without id arguments
is there plans to add / handle multiple redirection-procs in one cmd in the jobs table On Thu, Oct 17, 2024, 23:15 Chet Ramey wrote: > On 9/22/24 1:48 PM, Zachary Santer wrote: > > If you're not going to make 'wait -n' without id > > arguments pull something from the bgp list, then the 'set -o posix' > > notification behavior ought to be made the default behavior, yeah. > > I think keeping posix mode behavior is fine. > > >> Like `set -b'? > > > > Yeah, that really needs to be mentioned explicitly. > > The job control section already mentions notify, and the latest (heavily > edited) versions mention that jobs are removed from the jobs table when > the user is notified. > > > > If the default > > notification behavior stays as is, it should also mention that 'wait > > -n' without id arguments in the interactive shell, with 'set -m' > > enabled, requires that 'set -o posix' be enabled as well, for reliable > > I could see putting all that in the BUGS section. > > > > It's not a bug. I mean, I know there's some stuff in the BUGS section > that's not a bug that's been there for a while, but this isn't a bug. > It's just how notify works. > > > I know I never looked at it before I got burnt the first time. > > Apparently. > > > > >>> B) Solve 'wait -n' inconsistency by allowing it to act on the list of > >>> saved pids and statuses of jobs whose termination has already been > >>> notified to the user: > >>> - POSIX doesn't agree with the existence of that list > >> > >> POSIX says everything should disappear when you get notified or the > >> subject of `wait', so there's that (bash just does it on `wait'). Those > >> semantics have defenders just as ardent as you are. > > > > Maybe those defenders can elucidate what purpose that behavior would > serve. > > kre's on the list, maybe he'll speak up. I'm not going to speak for him. > He's written about this before. > > https://lists.gnu.org/archive/html/bug-bash/2024-08/msg00124.html > https://lists.gnu.org/archive/html/bug-bash/2024-08/msg00179.html > > > At the end of the day, B) is by far the simpler solution, and wouldn't > > leave a bunch of configurations where 'wait -n' doesn't really work > > quite right in the interactive shell. > > It will work that way in posix mode for now. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: bash -xv issue with stderr
i doubt its 'bminor' he talks about bash git on savannah .. i think .. On Mon, Nov 4, 2024, 09:21 Christoph Zimmermann wrote: > Hi Chat, > > As I can't seem to find this: You are referring to the 'devel' branch at > https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)? > > Cheers, Chris > > On 03.11.24 21:00, Chet Ramey wrote: > > On 11/3/24 5:28 AM, Christoph Zimmermann wrote: > >> Thanks for all the quick reactions on that issue (including microsuxx's > suggestion which > >> unfortunately does require a CB change). > >> > >> If this is intended behaviour, it should be clearly documented on the > corresponding man > >> page (which doesn't seem to be case ATM). > > > > The current devel branch man page and info file both specify that the > > xtrace output is written to stderr. > > > > -- > This email account is monitored seven days a week. > >
Re: bash -xv issue with stderr
u can just try the BASH_XTRACEFD=3 line w/o else ... and where u need set -xv output u capture the fd 3 or u can set -xv to 2 but apps to stderr use 3 On Sun, Nov 3, 2024, 13:45 Christoph Zimmermann wrote: > Thanks for all the quick reactions on that issue (including microsuxx's > suggestion which > unfortunately does require a CB change). > > If this is intended behaviour, it should be clearly documented on the > corresponding man > page (which doesn't seem to be case ATM). > > On 02.11.24 19:57, Chet Ramey wrote: > > On 11/2/24 1:41 PM, monochro...@linuxinlaws.eu wrote: > > > >> Bash Version: 5.2 > >> Patch Level: 37 > >> Release Status: release > >> > >> Description: > >> Redirecting stderr to file causes output of bash -xv to be > writte to file as well > > > > That's where the shell writes -v and -x output. > > > > -- > This email account is monitored seven days a week. > >
Re: bash -xv issue with stderr
~ $ bash mb.test.3stderr
+ echo foo
exec 3<&2
BASH_XTRACEFD=3
set -x
{
echo foo >&2
} 2>&-
On Sat, Nov 2, 2024, 19:25 wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: aarch64
> OS: darwin24.0.0
> Compiler: clang
> Compilation CFLAGS: -DSSH_SOURCE_BASHRC
> -DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/\
> bash:.'
> uname output: Darwin Christophs-MacBook-Air.local 24.1.0 Darwin Kernel
> Version 24.1.0: Thu Oct 10 21:05:14 PDT 2024;
> root:xnu-11215.41.3~2/RELEASE_ARM64_T8103 arm64
> Machine Type: aarch64-apple-darwin24.0.0
>
> Bash Version: 5.2
> Patch Level: 37
> Release Status: release
>
> Description:
> Redirecting stderr to file causes output of bash -xv to be writte
> to file as well
>
> Repeat-By:
>
> test_bash.sh:
> "
> test_fun() {
> echo "to stderr" >&2
> }
>
> test_fun &>out
> "
> bash -xv test_bash.sh:
> "
> test_fun() {
> echo "to stderr" >&2
> }
>
> test_fun &>out
> + test_fun
> "
>
> out:
> "
> + echo 'to stderr'
> to stderr
> "
>
> Fix:
>
>
Re: bash -xv issue with stderr
exec 3<&2
BASH_XTRACEFD=3
set -x
{
echo foo >&2
} 2>&-
replace &- with file to out log the echo
On Sat, Nov 2, 2024, 20:37 wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: aarch64
> OS: darwin24.0.0
> Compiler: clang
> Compilation CFLAGS: -DSSH_SOURCE_BASHRC
> -DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.'
> uname output: Darwin Christophs-MacBook-Air.local 24.1.0 Darwin Kernel
> Version 24.1.0: Thu Oct 10 21:05:14 PDT 2024;
> root:xnu-11215.41.3~2/RELEASE_ARM64_T8103 arm64
> Machine Type: aarch64-apple-darwin24.0.0
>
> Bash Version: 5.2
> Patch Level: 37
> Release Status: release
>
> Description:
> Redirecting stderr to file causes output of bash -xv to be writte
> to file as well
>
> Repeat-By:
>
> test_bash.sh:
> "
> test_fun() {
> echo "to stderr" >&2
> }
>
> test_fun &>out
> "
> bash -xv test_bash.sh:
> "
> test_fun() {
> echo "to stderr" >&2
> }
>
> test_fun &>out
> + test_fun
> "
>
> out:
> "
> + echo 'to stderr'
> to stderr
> "
>
> Fix:
>
>
>
Re: bash -xv issue with stderr
i think ..
BASH_XTRACEFD=3
.. alone may also do ..
u try ..
On Sat, Nov 2, 2024, 20:55 #!microsuxx wrote:
> exec 3<&2
> BASH_XTRACEFD=3
> set -x
> {
> echo foo >&2
> } 2>&-
>
> replace &- with file to out log the echo
>
> On Sat, Nov 2, 2024, 20:37 wrote:
>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: aarch64
>> OS: darwin24.0.0
>> Compiler: clang
>> Compilation CFLAGS: -DSSH_SOURCE_BASHRC
>> -DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.'
>> uname output: Darwin Christophs-MacBook-Air.local 24.1.0 Darwin Kernel
>> Version 24.1.0: Thu Oct 10 21:05:14 PDT 2024;
>> root:xnu-11215.41.3~2/RELEASE_ARM64_T8103 arm64
>> Machine Type: aarch64-apple-darwin24.0.0
>>
>> Bash Version: 5.2
>> Patch Level: 37
>> Release Status: release
>>
>> Description:
>> Redirecting stderr to file causes output of bash -xv to be writte
>> to file as well
>>
>> Repeat-By:
>>
>> test_bash.sh:
>> "
>> test_fun() {
>> echo "to stderr" >&2
>> }
>>
>> test_fun &>out
>> "
>> bash -xv test_bash.sh:
>> "
>> test_fun() {
>> echo "to stderr" >&2
>> }
>>
>> test_fun &>out
>> + test_fun
>> "
>>
>> out:
>> "
>> + echo 'to stderr'
>> to stderr
>> "
>>
>> Fix:
>>
>>
>>
Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}
On Thu, Nov 7, 2024, 21:10 Chet Ramey wrote:
> On 11/6/24 9:38 PM, David Linden wrote:
>
> > Bash Version: 4.4
> > Patch Level: 20
> > Release Status: release
> >
> > Description:
> > This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
> ${#foo[@]}
>
> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
> until it's been assigned a value. This fix aligns the array variable
> behavior with the scalar (non-array) variable behavior.
>
>
> > How am I supposed to determine that a declared associative array
> is empty?
>
to try to answer ' how to check if assoc arr is empty '
first [[ ${name@a} == *A* ]] or == A not sure
then in code
~/m $ cat m.test.emptyassoc
#!/bin/bash
c() {
local r=$@
eval -- "$r"
l
}
l() {
l1
}
r() {
eval "$@" &&
echo -e "$@\t\t$r"
}
l1() {
r [[ -v $n ]]
r "(( \${#$n[@]} ))"
}
unset -v assoc n
n=assoc
c : init
c declare -A assoc
c 'assoc+=( foo bar )'
c 'assoc+=( 2foo 2bar )'
c unset -v $n
~/m $ bash m.test.emptyassoc
[[ -v assoc ]] assoc+=( foo bar )
(( ${#assoc[@]} )) assoc+=( foo bar )
[[ -v assoc ]] assoc+=( 2foo 2bar )
(( ${#assoc[@]} )) assoc+=( 2foo 2bar )
therefore [[ -v and (( $# works
That's not the question that `set -u' answers. It will tell you whether
> a variable with attributes (or without) has been assigned a value.
>
> Does your code manage this variable? If it does, you should be able to
> determine whether or not it was ever assigned a value, or make sure
> that it has been assigned a value, if that's important. The empty array
> is a valid value, just like the empty string is a valid value for scalar
> variables.
>
> > Or even use it in a conditional even one where the value won't be
> evaluated?
>
what
What do you mean? Using something like foo[@] is fine in expansions
> where it won't be expanded:
>
> echo ${foo[@]-unset}
>
> or
>
> v=set; echo ${v:-foo[@]}
>
> But if you get into a case where the variable needs to be expanded,
> you're going to get an error if the variable isn't set.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}
On Thu, Nov 7, 2024, 23:36 #!microsuxx wrote:
>
>
> On Thu, Nov 7, 2024, 21:10 Chet Ramey wrote:
>
>> On 11/6/24 9:38 PM, David Linden wrote:
>>
>> > Bash Version: 4.4
>> > Patch Level: 20
>> > Release Status: release
>> >
>> > Description:
>> > This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
>> ${#foo[@]}
>>
>> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
>> until it's been assigned a value. This fix aligns the array variable
>> behavior with the scalar (non-array) variable behavior.
>>
>>
>> > How am I supposed to determine that a declared associative array
>> is empty?
>>
>
> to try to answer ' how to check if assoc arr is empty '
> first [[ ${name@a} == *A* ]] or == A not sure
>
> then in code
>
> ~/m $ cat m.test.emptyassoc
> #!/bin/bash
>
> c() {
> local r=$@
> eval -- "$r"
> l
> }
>
> l() {
> l1
> }
>
> r() {
> eval "$@" &&
> echo -e "$@\t\t$r"
> }
>
> l1() {
> r [[ -v $n ]]
> r "(( \${#$n[@]} ))"
> }
>
> unset -v assoc n
> n=assoc
>
> c : init
> c declare -A assoc
> c 'assoc+=( foo bar )'
> c 'assoc+=( 2foo 2bar )'
> c unset -v $n
>
> ~/m $ bash m.test.emptyassoc
> [[ -v assoc ]] assoc+=( foo bar )
> (( ${#assoc[@]} )) assoc+=( foo bar )
> [[ -v assoc ]] assoc+=( 2foo 2bar )
> (( ${#assoc[@]} )) assoc+=( 2foo 2bar )
>
> therefore [[ -v and (( $# works
>
> That's not the question that `set -u' answers. It will tell you whether
>> a variable with attributes (or without) has been assigned a value.
>>
>> Does your code manage this variable? If it does, you should be able to
>> determine whether or not it was ever assigned a value, or make sure
>> that it has been assigned a value, if that's important. The empty array
>> is a valid value, just like the empty string is a valid value for scalar
>> variables.
>>
>> > Or even use it in a conditional even one where the value won't be
>> evaluated?
>
>
[[ -v assoc[\$elem] ]] if set , not checked if empty or not
else
[[ ${assoc[$elem]} ]]
what
>
> What do you mean? Using something like foo[@] is fine in expansions
>> where it won't be expanded:
>>
>> echo ${foo[@]-unset}
>>
>> or
>>
>> v=set; echo ${v:-foo[@]}
>>
>> But if you get into a case where the variable needs to be expanded,
>> you're going to get an error if the variable isn't set.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>> ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>>
>
Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}
sorry code cleaned up : it was more and stuff
c() {
eval -- "$@"
l
}
l() {
r [[ -v $n ]]
r "(( \${#$n[@]} ))"
}
r() {
eval "$@" &&
echo -e "$@\t\t$r"
}
c unset -v assoc
c declare -A assoc
c 'assoc+=( foo bar )'
c 'assoc+=( 2foo 2bar )'
c unset -v assoc
On Thu, Nov 7, 2024, 23:36 #!microsuxx wrote:
>
>
> On Thu, Nov 7, 2024, 21:10 Chet Ramey wrote:
>
>> On 11/6/24 9:38 PM, David Linden wrote:
>>
>> > Bash Version: 4.4
>> > Patch Level: 20
>> > Release Status: release
>> >
>> > Description:
>> > This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
>> ${#foo[@]}
>>
>> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
>> until it's been assigned a value. This fix aligns the array variable
>> behavior with the scalar (non-array) variable behavior.
>>
>>
>> > How am I supposed to determine that a declared associative array
>> is empty?
>>
>
> to try to answer ' how to check if assoc arr is empty '
> first [[ ${name@a} == *A* ]] or == A not sure
>
> then in code
>
> ~/m $ cat m.test.emptyassoc
> #!/bin/bash
>
> c() {
> local r=$@
> eval -- "$r"
> l
> }
>
> l() {
> l1
> }
>
> r() {
> eval "$@" &&
> echo -e "$@\t\t$r"
> }
>
> l1() {
> r [[ -v $n ]]
> r "(( \${#$n[@]} ))"
> }
>
> unset -v assoc n
> n=assoc
>
> c : init
> c declare -A assoc
> c 'assoc+=( foo bar )'
> c 'assoc+=( 2foo 2bar )'
> c unset -v $n
>
> ~/m $ bash m.test.emptyassoc
> [[ -v assoc ]] assoc+=( foo bar )
> (( ${#assoc[@]} )) assoc+=( foo bar )
> [[ -v assoc ]] assoc+=( 2foo 2bar )
> (( ${#assoc[@]} )) assoc+=( 2foo 2bar )
>
> therefore [[ -v and (( $# works
>
> That's not the question that `set -u' answers. It will tell you whether
>> a variable with attributes (or without) has been assigned a value.
>>
>> Does your code manage this variable? If it does, you should be able to
>> determine whether or not it was ever assigned a value, or make sure
>> that it has been assigned a value, if that's important. The empty array
>> is a valid value, just like the empty string is a valid value for scalar
>> variables.
>>
>> > Or even use it in a conditional even one where the value won't be
>> evaluated?
>>
>
> what
>
> What do you mean? Using something like foo[@] is fine in expansions
>> where it won't be expanded:
>>
>> echo ${foo[@]-unset}
>>
>> or
>>
>> v=set; echo ${v:-foo[@]}
>>
>> But if you get into a case where the variable needs to be expanded,
>> you're going to get an error if the variable isn't set.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>> ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>>
>
Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}
there is still code fault $n is supposed to be 'assoc' im sorry bye
On Thu, Nov 7, 2024, 23:44 #!microsuxx wrote:
> sorry code cleaned up : it was more and stuff
>
> c() {
> eval -- "$@"
> l
> }
>
> l() {
> r [[ -v $n ]]
> r "(( \${#$n[@]} ))"
> }
>
> r() {
> eval "$@" &&
> echo -e "$@\t\t$r"
> }
>
> c unset -v assoc
> c declare -A assoc
> c 'assoc+=( foo bar )'
> c 'assoc+=( 2foo 2bar )'
> c unset -v assoc
>
> On Thu, Nov 7, 2024, 23:36 #!microsuxx wrote:
>
>>
>>
>> On Thu, Nov 7, 2024, 21:10 Chet Ramey wrote:
>>
>>> On 11/6/24 9:38 PM, David Linden wrote:
>>>
>>> > Bash Version: 4.4
>>> > Patch Level: 20
>>> > Release Status: release
>>> >
>>> > Description:
>>> > This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
>>> ${#foo[@]}
>>>
>>> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
>>> until it's been assigned a value. This fix aligns the array variable
>>> behavior with the scalar (non-array) variable behavior.
>>>
>>>
>>> > How am I supposed to determine that a declared associative array
>>> is empty?
>>>
>>
>> to try to answer ' how to check if assoc arr is empty '
>> first [[ ${name@a} == *A* ]] or == A not sure
>>
>> then in code
>>
>> ~/m $ cat m.test.emptyassoc
>> #!/bin/bash
>>
>> c() {
>> local r=$@
>> eval -- "$r"
>> l
>> }
>>
>> l() {
>> l1
>> }
>>
>> r() {
>> eval "$@" &&
>> echo -e "$@\t\t$r"
>> }
>>
>> l1() {
>> r [[ -v $n ]]
>> r "(( \${#$n[@]} ))"
>> }
>>
>> unset -v assoc n
>> n=assoc
>>
>> c : init
>> c declare -A assoc
>> c 'assoc+=( foo bar )'
>> c 'assoc+=( 2foo 2bar )'
>> c unset -v $n
>>
>> ~/m $ bash m.test.emptyassoc
>> [[ -v assoc ]] assoc+=( foo bar )
>> (( ${#assoc[@]} )) assoc+=( foo bar )
>> [[ -v assoc ]] assoc+=( 2foo 2bar )
>> (( ${#assoc[@]} )) assoc+=( 2foo 2bar )
>>
>> therefore [[ -v and (( $# works
>>
>> That's not the question that `set -u' answers. It will tell you whether
>>> a variable with attributes (or without) has been assigned a value.
>>>
>>> Does your code manage this variable? If it does, you should be able to
>>> determine whether or not it was ever assigned a value, or make sure
>>> that it has been assigned a value, if that's important. The empty array
>>> is a valid value, just like the empty string is a valid value for scalar
>>> variables.
>>>
>>> > Or even use it in a conditional even one where the value won't
>>> be evaluated?
>>>
>>
>> what
>>
>> What do you mean? Using something like foo[@] is fine in expansions
>>> where it won't be expanded:
>>>
>>> echo ${foo[@]-unset}
>>>
>>> or
>>>
>>> v=set; echo ${v:-foo[@]}
>>>
>>> But if you get into a case where the variable needs to be expanded,
>>> you're going to get an error if the variable isn't set.
>>>
>>> --
>>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>> ``Ars longa, vita brevis'' - Hippocrates
>>> Chet Ramey, UTech, CWRUc...@case.edu
>>> http://tiswww.cwru.edu/~chet/
>>>
>>
Re: "printf %d ''" should diagnose the empty string
the printf %d gets to be no print_out at all u specify a % but no arg means it wont try printf at all smth printf %d '' we can talk about returns 0 and looks normal so to me On Tue, Nov 19, 2024, 8:46 PM Paul Eggert wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc -std=gnu23 > Compilation CFLAGS: -g -O2 > uname output: Linux penguin.cs.ucla.edu 6.11.6-200.fc40.x86_64 #1 SMP > PREEMPT_DYNAMIC Fri Nov 1 16:09:34 UTC 2024 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.3 > Patch Level: 0 > Release Status: beta > > Description: > > printf doesn't diagnose attempts to print empty strings as numbers. This > doesn't conform to POSIX and disagrees with the traditional Unix printf > command. > > Repeat-By: > > printf %d '' > > This should behave like "printf %d ' '", and should output a diagnostic > and exit with status 1; instead it silently exits with status 0. > > Fix: > Attached.
Re: "printf %d ''" should diagnose the empty string
On Tue, Nov 19, 2024, 10:04 PM #!microsuxx wrote: > the printf %d gets to be no print_out at all > u specify a % but no arg > means it wont try printf at all smth > > printf %d '' we can talk about > returns 0 > and looks normal so to me > sorry i missed u already did right sorry .. u can try posix mode if u care i .. like it not erroring On Tue, Nov 19, 2024, 8:46 PM Paul Eggert wrote: > >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc -std=gnu23 >> Compilation CFLAGS: -g -O2 >> uname output: Linux penguin.cs.ucla.edu 6.11.6-200.fc40.x86_64 #1 SMP >> PREEMPT_DYNAMIC Fri Nov 1 16:09:34 UTC 2024 x86_64 GNU/Linux >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 5.3 >> Patch Level: 0 >> Release Status: beta >> >> Description: >> >> printf doesn't diagnose attempts to print empty strings as numbers. This >> doesn't conform to POSIX and disagrees with the traditional Unix printf >> command. >> >> Repeat-By: >> >> printf %d '' >> >> This should behave like "printf %d ' '", and should output a diagnostic >> and exit with status 1; instead it silently exits with status 0. >> >> Fix: >> Attached. > >
Re: fg via keybind modifies tty settings
ah and to save and have it copy it into .bash_profile or .profile On Sat, Nov 16, 2024, 9:15 PM #!microsuxx wrote: > so , this is using the logic that vim returns a specific code 148 on > control-z > checking $? for it is what i did , for your request .. > > that thats a bit more clear , we can go on with testing > > copypaste the first small code in a terminal > and proceed with vim c-z testing > > the second longer is only for when u wanna match that the 148 returned > process for stty sane is 'vim*'' > > i suggest u stick to the first small code and copy the bigger one for just > so to have it > > greets > > > On Sat, Nov 16, 2024, 7:52 PM David Moberg wrote: > >> That looks very complicated, how do interpret that? And where/when to run >> it? >> >> Den lör 16 nov. 2024 16:48#!microsuxx skrev: >> >>> trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] && >>> bashcmd=$BASH_COMMAND ' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd >>> == vim* ]] && echo ye && stty sane ' >>> >>> On Sat, Nov 16, 2024, 4:40 PM #!microsuxx wrote: >>> >>>> PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane ' >>>> >>>> On Sat, Nov 16, 2024, 11:29 AM David Moberg wrote: >>>> >>>>> Ok, is there anything I can do on my user side to get desired behavior? >>>>> (similar to running `stty sane` every time I send vim to the >>>>> background.) >>>>> >>>>> Den tis 12 nov. 2024 16:49Chet Ramey skrev: >>>>> >>>>> > On 11/10/24 7:14 PM, Martin D Kealey wrote: >>>>> > >>>>> > > Perhaps what's really needed is to make sure that "ordinary" >>>>> commands >>>>> > bound >>>>> > > using bash -x are completely broken (so people won't try to use >>>>> them), >>>>> > > rather than almost working. >>>>> > >>>>> > `Ordinary' commands aren't broken. Programs like vim that modify the >>>>> > terminal settings, which are in the minority, are. >>>>> > >>>>> > -- >>>>> > ``The lyf so short, the craft so long to lerne.'' - Chaucer >>>>> > ``Ars longa, vita brevis'' - Hippocrates >>>>> > Chet Ramey, UTech, CWRUc...@case.edu >>>>> http://tiswww.cwru.edu/~chet/ >>>>> > >>>>> >>>>
Re: fg via keybind modifies tty settings
so , this is using the logic that vim returns a specific code 148 on control-z checking $? for it is what i did , for your request .. that thats a bit more clear , we can go on with testing copypaste the first small code in a terminal and proceed with vim c-z testing the second longer is only for when u wanna match that the 148 returned process for stty sane is 'vim*'' i suggest u stick to the first small code and copy the bigger one for just so to have it greets On Sat, Nov 16, 2024, 7:52 PM David Moberg wrote: > That looks very complicated, how do interpret that? And where/when to run > it? > > Den lör 16 nov. 2024 16:48#!microsuxx skrev: > >> trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] && >> bashcmd=$BASH_COMMAND ' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd >> == vim* ]] && echo ye && stty sane ' >> >> On Sat, Nov 16, 2024, 4:40 PM #!microsuxx wrote: >> >>> PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane ' >>> >>> On Sat, Nov 16, 2024, 11:29 AM David Moberg wrote: >>> >>>> Ok, is there anything I can do on my user side to get desired behavior? >>>> (similar to running `stty sane` every time I send vim to the >>>> background.) >>>> >>>> Den tis 12 nov. 2024 16:49Chet Ramey skrev: >>>> >>>> > On 11/10/24 7:14 PM, Martin D Kealey wrote: >>>> > >>>> > > Perhaps what's really needed is to make sure that "ordinary" >>>> commands >>>> > bound >>>> > > using bash -x are completely broken (so people won't try to use >>>> them), >>>> > > rather than almost working. >>>> > >>>> > `Ordinary' commands aren't broken. Programs like vim that modify the >>>> > terminal settings, which are in the minority, are. >>>> > >>>> > -- >>>> > ``The lyf so short, the craft so long to lerne.'' - Chaucer >>>> > ``Ars longa, vita brevis'' - Hippocrates >>>> > Chet Ramey, UTech, CWRUc...@case.edu >>>> http://tiswww.cwru.edu/~chet/ >>>> > >>>> >>>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
another solution if u parse output u can intercept and parse without piping exec 2> >( stderr_parser_cmd ) 1> >( stdout parser cmd ) or both in one or or another one : exec >>log 2>&1 set -x . cmd i just dunno the exec cmd to bring back the fd 1 and 2 after usage back to tty , or restore from saved u can also eval " &( < a.bash ) " and anotherone is using $LINENO or some similiar value , on error On Thu, Nov 14, 2024, 12:09 AM #!microsuxx wrote: > source is not tty dependand , so try .. > > tee -a log < <( > exec 2>&1 > set -x > . user.bash > ) > > On Wed, Nov 13, 2024, 11:52 PM Yuri wrote: > >> On 11/13/24 14:45, #!microsuxx wrote: >> > depending on actual purpose instead bs demo code , there are serval >> > approaches to code running code >> >> >> The original code in my project runs 'source x.sh > log' where x.sh is >> some user-provided script. >> >> I wanted to trace the code using 'set -x' in order to report errors >> locations in scripts to the user. >> However, the trace also goes to log instead of stdout. >> When I changed that to 'source x.sh | tee log' - environment variables >> that the user script x.sh also sets disappeared due to the problem in >> SUBJECT. >> >> >> This problem makes it very inconvenient to implement features around >> scripts using 'source'. >> >> >> >> Yuri >> >> >> >>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
what u need to do with the vars
include all code in tee
or try
exec > >( tee -a log ) 2>&1
set -x
. my.bash
...
what i firstly meant :
#!/bin/bash
tee -a log < <(
all code here
set -x ; . code ; other code that needs the vars set
maybe needs a 2> smth
)
try
(
set -x
. mybash
vars_code
) |& tee -a log
On Thu, Nov 14, 2024, 12:19 AM Yuri wrote:
> On 11/13/24 14:48, #!microsuxx wrote:
> > 1st source cmd , no extra cmds 2. { . foo ; code ; code ; } | tee 3rd
> > tee < <( . foo ; cmds )
>
>
> I need to (1) source the user script, (2) save this script's output to a
> dedicated file, (3) keep the same output in stdout, and (4) keep
> environment variables that the user script sets for later commands.
> It doesn't look like any of the above 3 lines do all these 4 requirements.
>
>
> Yuri
>
>
>
>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
if u dont need stderr even simpler
On Thu, Nov 14, 2024, 12:36 AM #!microsuxx wrote:
> what u need to do with the vars
> include all code in tee
> or try
>
> exec > >( tee -a log ) 2>&1
> set -x
> . my.bash
> ...
>
> what i firstly meant :
>
> #!/bin/bash
> tee -a log < <(
> all code here
> set -x ; . code ; other code that needs the vars set
> maybe needs a 2> smth
> )
>
> try
>
> (
> set -x
> . mybash
> vars_code
> ) |& tee -a log
>
>
> On Thu, Nov 14, 2024, 12:19 AM Yuri wrote:
>
>> On 11/13/24 14:48, #!microsuxx wrote:
>> > 1st source cmd , no extra cmds 2. { . foo ; code ; code ; } | tee 3rd
>> > tee < <( . foo ; cmds )
>>
>>
>> I need to (1) source the user script, (2) save this script's output to a
>> dedicated file, (3) keep the same output in stdout, and (4) keep
>> environment variables that the user script sets for later commands.
>> It doesn't look like any of the above 3 lines do all these 4 requirements.
>>
>>
>> Yuri
>>
>>
>>
>>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
depending on actual purpose instead bs demo code , there are serval approaches to code running code On Wed, Nov 13, 2024, 11:13 PM Yuri wrote: > On 11/13/24 14:02, Greg Wooledge wrote: > > The commands within a pipeline are executed in subshells (child > > processes), so all variable changes are discarded when the subshell > exits. > > > This sounds like an implementation detail that should be invisible that > affects how the 'source' feature works. > This makes it a very confusing from the user's perspective. > > > > > Yuri > > > >
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
eg in ur puroose u dont need source
and in ur code when u understood | othercmd is in another subshell , u see
it doesnt well
if u pipe to tee , .. well the scope of needed
1st source cmd , no extra cmds
2. { . foo ; code ; code ; } | tee
3rd tee < <( . foo ; cmds )
On Wed, Nov 13, 2024, 11:45 PM #!microsuxx wrote:
> depending on actual purpose instead bs demo code , there are serval
> approaches to code running code
>
> On Wed, Nov 13, 2024, 11:13 PM Yuri wrote:
>
>> On 11/13/24 14:02, Greg Wooledge wrote:
>> > The commands within a pipeline are executed in subshells (child
>> > processes), so all variable changes are discarded when the subshell
>> exits.
>>
>>
>> This sounds like an implementation detail that should be invisible that
>> affects how the 'source' feature works.
>> This makes it a very confusing from the user's perspective.
>>
>>
>>
>>
>> Yuri
>>
>>
>>
>>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
source is not tty dependand , so try .. tee -a log < <( exec 2>&1 set -x . user.bash ) On Wed, Nov 13, 2024, 11:52 PM Yuri wrote: > On 11/13/24 14:45, #!microsuxx wrote: > > depending on actual purpose instead bs demo code , there are serval > > approaches to code running code > > > The original code in my project runs 'source x.sh > log' where x.sh is > some user-provided script. > > I wanted to trace the code using 'set -x' in order to report errors > locations in scripts to the user. > However, the trace also goes to log instead of stdout. > When I changed that to 'source x.sh | tee log' - environment variables > that the user script x.sh also sets disappeared due to the problem in > SUBJECT. > > > This problem makes it very inconvenient to implement features around > scripts using 'source'. > > > > Yuri > > > >
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
i agree its hard to , say , comm clearly together i suggest for next times more real life true examples op's msgs werent so much detailed , more bla-neric :)) greets all On Thu, Nov 14, 2024, 1:35 AM Robert Elz wrote: > Date:Wed, 13 Nov 2024 15:18:58 -0800 > From:Yuri > Message-ID: > > | I need to (1) source the user script, (2) save this script's output to > a > | dedicated file, (3) keep the same output in stdout, and (4) keep > | environment variables that the user script sets for later commands. > | It doesn't look like any of the above 3 lines do all these 4 > requirements. > > Sometimes you can't always have what you need - there probably are > methods here, but before solving this problem someone should find out > whether it really needs to be solved. > > That is, far too often people determine what they think they need to do > to solve some problem, discover that what they think they need to do is > hard, so ask for help doing that hard thing - often with mixed results. > > If there was an explanation of what the issue really is that led you to > believe that you need those 4 things, perhaps someone might be able to > show you that you really don't - that this is not the correct approach > to solving the real problem, and there is a much better way. > > But as long as you continue chasing down this rabbit hole, that will > never happen. > > kre > > >
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
On Thu, Nov 14, 2024, 12:57 AM Yuri wrote: > On 11/13/24 15:44, Greg Wooledge wrote: > > If the "user script" runs quickly enough, then: source userscript > > >logfile 2>&1 cat logfile > > > This would fail to save the user script's output in case it would > execute "exit 1" > the >logfile makes it overwrite just from the two quoted lines > > > Yuri > > > >
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
u need to , save out of . script1 to log1 but what was your second sentense alike of this first one ? u run source over log1 to produce log2 ? i thought ur looking for errors and for this set -x and stderr ? no need for both ? i need some details clarified .. On Thu, Nov 14, 2024, 12:48 AM Yuri wrote: > Hi !microsuxx, > > > But I need to save the output of the user script into a dedicated log file. > This script should run, should save its output into a dedicated log, and > then many other commands should use these environment variables. > > Their logs can't be combined into one. > > > Yuri > > > > On 11/13/24 15:36, #!microsuxx wrote: > > what u need to do with the vars include all code in tee or try exec > > > >( tee -a log ) 2>&1 set -x . my.bash ... what i firstly meant : > > #!/bin/bash tee -a log < <( all code here set -x ; . code ; other code > > that needs the vars set maybe needs a 2> smth ) try ( set -x . mybash > > vars_code ) |& tee -a log > > >
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
try .. exec 3> >( tee -a log ) # or 3>> . user.bash >&3 cmds ; cmds ; vars ; cmds On Thu, Nov 14, 2024, 12:56 AM #!microsuxx wrote: > u need to , save out of . script1 to log1 but what was your second > sentense alike of this first one ? > u run source over log1 to produce log2 ? > > i thought ur looking for errors and for this set -x and stderr ? no need > for both ? > > i need some details clarified .. > > On Thu, Nov 14, 2024, 12:48 AM Yuri wrote: > >> Hi !microsuxx, >> >> >> But I need to save the output of the user script into a dedicated log >> file. >> This script should run, should save its output into a dedicated log, and >> then many other commands should use these environment variables. >> >> Their logs can't be combined into one. >> >> >> Yuri >> >> >> >> On 11/13/24 15:36, #!microsuxx wrote: >> > what u need to do with the vars include all code in tee or try exec > >> > >( tee -a log ) 2>&1 set -x . my.bash ... what i firstly meant : >> > #!/bin/bash tee -a log < <( all code here set -x ; . code ; other code >> > that needs the vars set maybe needs a 2> smth ) try ( set -x . mybash >> > vars_code ) |& tee -a log >> >> >>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
maybe ur email formats it wrong those are two lines , by greg not one anyway if u append more than one cmd to logfile more than one source cmd u need to use >>logfile instead of >logfile On Thu, Nov 14, 2024, 1:00 AM #!microsuxx wrote: > > > On Thu, Nov 14, 2024, 12:57 AM Yuri wrote: > >> On 11/13/24 15:44, Greg Wooledge wrote: >> > If the "user script" runs quickly enough, then: source userscript >> > >logfile 2>&1 cat logfile >> >> >> This would fail to save the user script's output in case it would >> execute "exit 1" >> > > the >logfile makes it overwrite > just from the two quoted lines > >> >> >> Yuri >> >> >> >>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
also u need to $log may i ask what criteria ur scripts are about a $log can be log=/tmp/my.log.$USER.$SRANDOM On Thu, Nov 14, 2024, 1:04 AM #!microsuxx wrote: > maybe ur email formats it wrong > those are two lines , by greg > not one > > anyway if u append more than one cmd to logfile > more than one source cmd > u need to use >>logfile instead of >logfile > > On Thu, Nov 14, 2024, 1:00 AM #!microsuxx wrote: > >> >> >> On Thu, Nov 14, 2024, 12:57 AM Yuri wrote: >> >>> On 11/13/24 15:44, Greg Wooledge wrote: >>> > If the "user script" runs quickly enough, then: source userscript >>> > >logfile 2>&1 cat logfile >>> >>> >>> This would fail to save the user script's output in case it would >>> execute "exit 1" >>> >> >> the >logfile makes it overwrite >> just from the two quoted lines >> >>> >>> >>> Yuri >>> >>> >>> >>>
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
maybe set -a 'd help ? if it can backwards export the vars On Thu, Nov 14, 2024, 3:01 PM Chet Ramey wrote: > On 11/13/24 4:48 PM, Yuri wrote: > > > The first 'source' command didn't set variables set or exported in the > > child.sh script, even though 'source' is executed in the current > script's > > context, > > The `source' command isn't "executed in the current script's context." It > is executed in a subshell, which can't affect its parent's variables. > > The bash man page says: > > "Each command in a multi-command pipeline, where pipes are created, is > executed in a subshell, which is a separate process." > > POSIX says: > > "Changes made to the subshell environment shall not affect the shell > environment. Command substitution, commands that are grouped with > parentheses, and asynchronous AND-OR lists shall be executed in a > subshell > environment. Additionally, each command of a multi-command pipeline is in > a subshell environment;" > > Some shells, including bash in some circumstances, will execute the last > pipeline element in the current shell, but no shell executes the first > element in the current shell context. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
aidd , thxx .. ++ On Thu, Nov 14, 2024, 8:45 PM Chet Ramey wrote: > On 11/14/24 2:28 PM, #!microsuxx wrote: > > maybe set -a 'd help ? > > if it can backwards export the vars > > No. A child process can't affect its parent's environment without inventing > some kind of IPC. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
another code is if u wanna not use . or eval or bash cmd ( . is source ) shopt -s expand_aliases alias script=" $( < user.bash ) " script On Thu, Nov 14, 2024, 1:10 AM #!microsuxx wrote: > also u need to $log > may i ask what criteria ur scripts are about > > a $log can be > > log=/tmp/my.log.$USER.$SRANDOM > > On Thu, Nov 14, 2024, 1:04 AM #!microsuxx wrote: > >> maybe ur email formats it wrong >> those are two lines , by greg >> not one >> >> anyway if u append more than one cmd to logfile >> more than one source cmd >> u need to use >>logfile instead of >logfile >> >> On Thu, Nov 14, 2024, 1:00 AM #!microsuxx wrote: >> >>> >>> >>> On Thu, Nov 14, 2024, 12:57 AM Yuri wrote: >>> >>>> On 11/13/24 15:44, Greg Wooledge wrote: >>>> > If the "user script" runs quickly enough, then: source userscript >>>> > >logfile 2>&1 cat logfile >>>> >>>> >>>> This would fail to save the user script's output in case it would >>>> execute "exit 1" >>>> >>> >>> the >logfile makes it overwrite >>> just from the two quoted lines >>> >>>> >>>> >>>> Yuri >>>> >>>> >>>> >>>>
Re: fg via keybind modifies tty settings
PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane ' On Sat, Nov 16, 2024, 11:29 AM David Moberg wrote: > Ok, is there anything I can do on my user side to get desired behavior? > (similar to running `stty sane` every time I send vim to the background.) > > Den tis 12 nov. 2024 16:49Chet Ramey skrev: > > > On 11/10/24 7:14 PM, Martin D Kealey wrote: > > > > > Perhaps what's really needed is to make sure that "ordinary" commands > > bound > > > using bash -x are completely broken (so people won't try to use them), > > > rather than almost working. > > > > `Ordinary' commands aren't broken. Programs like vim that modify the > > terminal settings, which are in the minority, are. > > > > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > > ``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, UTech, CWRUc...@case.edu > http://tiswww.cwru.edu/~chet/ > > >
Re: fg via keybind modifies tty settings
trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] && bashcmd=$BASH_COMMAND ' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd == vim* ]] && echo ye && stty sane ' On Sat, Nov 16, 2024, 4:40 PM #!microsuxx wrote: > PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane ' > > On Sat, Nov 16, 2024, 11:29 AM David Moberg wrote: > >> Ok, is there anything I can do on my user side to get desired behavior? >> (similar to running `stty sane` every time I send vim to the background.) >> >> Den tis 12 nov. 2024 16:49Chet Ramey skrev: >> >> > On 11/10/24 7:14 PM, Martin D Kealey wrote: >> > >> > > Perhaps what's really needed is to make sure that "ordinary" commands >> > bound >> > > using bash -x are completely broken (so people won't try to use them), >> > > rather than almost working. >> > >> > `Ordinary' commands aren't broken. Programs like vim that modify the >> > terminal settings, which are in the minority, are. >> > >> > -- >> > ``The lyf so short, the craft so long to lerne.'' - Chaucer >> > ``Ars longa, vita brevis'' - Hippocrates >> > Chet Ramey, UTech, CWRUc...@case.edu >> http://tiswww.cwru.edu/~chet/ >> > >> >
Re: doc-strings of the 'command' built-in, as output by help
~ $ command -v bash /data/data/com.termux/files/usr/bin/bash ~ $ command -V bash bash is /data/data/com.termux/files/usr/bin/bash V adds english text On Tue, Nov 26, 2024, 3:44 AM Lawrence Velázquez wrote: > On Mon, Nov 25, 2024, at 9:03 PM, Martin D Kealey wrote: > > I keep "similar" there because ‘type -a COMMAND’ shows all possible > matches > > for COMMAND, whereas ‘command -V’ only does that when COMMAND is NOT an > > alias. > > I'm not seeing that "command -V" behavior. > > $ type -a bash > bash is /opt/local/bin/bash > bash is /bin/bash > $ command -V bash > bash is /opt/local/bin/bash > > -- > vq > >
Re: Documenting Bash’s Tilde Expansion in PATH: A Proposal for Clarity and Compatibility
ah , this might be due to u use it after a bash keyword 1. it doesnt need export cause its already exported 2. if u wanna export , export it but 3. do PATH='...' or ".." ur string but not after export or declare just on its own line greets On Tue, Feb 4, 2025, 4:53 AM Zeffie wrote: > On 2025-02-03 22:19, microsuxx wrote: > > > ~ $ p=~:~:~ ; declare -p p > > declare -- > > > p="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home" > > > > ~ $ cp $( type -P bash ) sh > > ~ $ ./sh > > sh-5.2$ x=~:~:~: > > sh-5.2$ declare -p x > > declare -- > > > x="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home:" > > > > sh-5.2$ set -o posix > > sh-5.2$ f=~:~:~ > > sh-5.2$ declare -p f > > declare -- > > > f="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home" > > > > im under the impression > > by ur code examples > > .. in quotes , ~ doesnt expand > > > > This demonstration confirms that in Bash, an unquoted tilde (e.g. ~) in > a variable assignment is immediately expanded to the full home > directory—this happens consistently whether Bash is running normally, as > sh, or in POSIX mode. However, when used in the PATH variable, > interactive Bash expands the tilde at command execution time while > sh/Posix mode does not, which can lead to unexpected behavior. For > portability, it's best to use $HOME explicitly (e.g. $HOME/bin), and > this inconsistency should be clearly documented in the Bash Reference > Manual. > > Zeffie >
Re: DKIM Signature Issue Causing Mailing List Posts to be Marked as Spam
dude u cant whitelist it or smth .. ? On Tue, Feb 4, 2025, 3:00 AM Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > Thank you for your thoughts. While I appreciate your perspective on DKIM > and spam filtering, I expect the list maintainers to handle these issues > properly. I've been running mail servers since the 1990s, so I > understand the complexities involved. Even if many messages on the list > aren’t signed or DKIM isn’t widely used, it’s still the responsibility > of the list maintainer to ensure that legitimate posts aren’t > misclassified as spam. > > I understand that some believe filtering based on DKIM is misguided, but > if the From header is being altered by the list to work around other > spam protection measures, then it's incumbent upon the list > administrators to resolve the resulting DKIM validation failures. I > expect that those with the appropriate authority will review and address > this matter to prevent further disruptions to our technical discussions. > > Thanks again for sharing your views. > > Zeffie > >
Re: [SPAM] Re: [PATCH] Preserve echoctl setting in sh‑mode (lib/sh/shtty.c)
look dude , i looked at the link flying by by long texts and no clear examples this n that try , providing _all_ _exact_ cmds to reproduce it , in once , here and on ur other list then shtuff may change .. greets On Tue, Feb 4, 2025, 12:44 AM Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > On 2025-02-03 18:14, microsuxx wrote: > > i suggest u be some kinder .. > > > > I have a long history on various Linux forums and always strive to > remain polite and respectful. However, I have a very low tolerance for > practices like top posting and responses that seem nonsensical or > dismissive. As someone who has maintained projects for many years, I > believe that every technical comment deserves thoughtful consideration, > and dismissing feedback without a genuine discussion is not acceptable. > I value constructive debate and expect the same level of respect and > clarity from all participants. > > I also hope that my previous post helps the maintainer understand the > problem more clearly so that we can work together to address it > effectively. > > Zeffie > >
Re: [SPAM] Re: [PATCH] Preserve echoctl setting in sh‑mode (lib/sh/shtty.c)
with all i mean freebsd ones On Tue, Feb 4, 2025, 4:12 AM microsuxx wrote: > look dude , > i looked at the link flying by > by long texts and no clear examples this n that > > try , providing _all_ _exact_ cmds to reproduce it , in once , here and on > ur other list > > then shtuff may change .. > > greets > > On Tue, Feb 4, 2025, 12:44 AM Zeffie via Bug reports for the GNU Bourne > Again SHell wrote: > >> On 2025-02-03 18:14, microsuxx wrote: >> > i suggest u be some kinder .. >> > >> >> I have a long history on various Linux forums and always strive to >> remain polite and respectful. However, I have a very low tolerance for >> practices like top posting and responses that seem nonsensical or >> dismissive. As someone who has maintained projects for many years, I >> believe that every technical comment deserves thoughtful consideration, >> and dismissing feedback without a genuine discussion is not acceptable. >> I value constructive debate and expect the same level of respect and >> clarity from all participants. >> >> I also hope that my previous post helps the maintainer understand the >> problem more clearly so that we can work together to address it >> effectively. >> >> Zeffie >> >>
Re: Documenting Bash’s Tilde Expansion in PATH: A Proposal for Clarity and Compatibility
~ $ p=~:~:~ ; declare -p p declare -- p="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home" ~ $ cp $( type -P bash ) sh ~ $ ./sh sh-5.2$ x=~:~:~: sh-5.2$ declare -p x declare -- x="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home:" sh-5.2$ set -o posix sh-5.2$ f=~:~:~ sh-5.2$ declare -p f declare -- f="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home" im under the impression by ur code examples .. in quotes , ~ doesnt expand greets On Tue, Feb 4, 2025, 2:04 AM Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > To whom it may concern, > > Bash has long maintained a legacy feature whereby, in interactive > sessions, a literal tilde (`~`) at the start of a `PATH` element (e.g., > `~/bin`) is expanded to the user’s home directory at the time a command > is executed. While this behavior can sometimes “help” users find > commands in their home directory, it is neither consistent with POSIX > nor universally understood. In particular, when Bash is invoked as > `/bin/sh` or in POSIX mode, tilde expansion in `PATH` is disabled, > leading to potential confusion and hard-to-debug issues. > > Given that a number of legacy systems and scripts may depend on this > behavior—and that it can easily be mistaken for a more portable > feature—the behavior should be formally documented. Furthermore, > preserving it (while discouraging its use in new code) spares users from > having to build custom versions of Bash for environments that rely on > this quirk. > > Why Document This Behavior? > > Clarity and Portability: > Many users naturally assume that writing > ```bash > export PATH="~/bin:$PATH" > ``` > is equivalent to > ```bash > export PATH="$HOME/bin:$PATH" > ``` > in all contexts. However, because Bash in interactive mode expands > the tilde at command execution time while POSIX mode (or `/bin/sh` > invocations) does not, scripts may work as expected in one context and > fail in another. Documenting this inconsistency would alert developers > to the subtle differences, promoting best practices in portable > scripting. > > Preventing Inadvertent Errors: > As legacy systems evolve and environments become more heterogeneous, > the likelihood of encountering the non-expanded tilde in non-interactive > contexts increases. Clear documentation would help prevent unexpected > command-not-found errors when scripts (or applications invoking > `system(3)`) rely on the interactive shell’s behavior. > > Historical Consistency and Backward Compatibility: > The behavior has been part of Bash since its early days. Removing or > modifying it without proper notice would break existing scripts that, > knowingly or not, depend on tilde expansion in the `PATH`. By > documenting the behavior—and marking it as legacy—we provide a clear > notice that while this feature is maintained for backward compatibility, > its use in new scripts is discouraged. > > Supporting Legacy Systems: > Numerous systems in the field, including embedded devices and > enterprise environments, might still be running scripts that use this > behavior. Maintaining and documenting it means that system > administrators and developers do not have to invest in building or > patching custom Bash versions to preserve compatibility. > > Proposed Additions to the Bash Reference Manual > > To address the above points, the following text (or similar language) is > proposed for inclusion in the Bash Reference Manual: > > Tilde Expansion in the `PATH` Variable > > Description: > In interactive Bash sessions, any element of the `PATH` variable that > begins with a tilde (e.g., `~` or `~/bin`) is automatically expanded to > the corresponding home directory of the current user at the time a > command is executed. For example, if the user's home directory is > `/home/alice`, then an entry `~/bin` in the `PATH` is interpreted as > `/home/alice/bin` during command lookup. > > Behavior Details: > > Interactive Bash: >When Bash is invoked in its default interactive mode, the tilde > expansion is performed as if the entry were unquoted. This expansion > occurs at the time of command execution and allows commands located in > the user’s home directory (e.g., in `/home/alice/bin`) to be found even > if the `PATH` contains a literal tilde. > > Bash in POSIX Mode or as `/bin/sh`: >When Bash is invoked as `/bin/sh` or with POSIX mode enabled (see > [Bash POSIX > Mode]( > https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html)), > > tilde expansion in `PATH` is not performed. In these contexts, a literal > tilde remains unexpanded, and any command lookup that relies on such > expansion will fail. > > Recommendations for Script Authors: > > For portable scripts and applications, it is recommended to explicitly > use the `$HOME` variable when specifying paths: >
Re: [PATCH] Preserve echoctl setting in sh‑mode (lib/sh/shtty.c)
i suggest u be some kinder .. On Mon, Feb 3, 2025, 11:43 PM Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > Thank you for taking the time to not review the FreeBSD bug report (Bug > 284513) in full before responding. Your willingness to speculate on > behaviors without testing in the relevant environment is duly noted and > much appreciated. > > Now, let’s break down the issues with your response: > > 1. `echo $BASH_VERSION` is Irrelevant > You seem to have completely misunderstood the context of the bug report. > The command: > > ```sh > echo $BASH_VERSION > ``` > is entirely irrelevant in this discussion because: > `BASH_VERSION` is only set when Bash is running as Bash. > > When Bash is invoked as `sh` (i.e., in sh-mode via symlink), it does not > necessarily set `BASH_VERSION` and behaves differently from its normal > interactive mode. > > The issue being reported occurs specifically in sh-mode, which means > that confirming `BASH_VERSION` only proves that you’re not testing the > relevant scenario. > > Your test confirms that you are running Bash in normal mode, not in > sh-mode. That is the opposite of what is required to reproduce the > issue. > > 2. Acknowledging That This Is a TTY Issue—Then Ignoring It > You admit: > > "I don't run FreeBSD, and I certainly don't run a serial terminal > configuration." > > > Yet, you then proceed to run tests without a serial terminal setup—the > very condition under which the bug manifests. If the issue only occurs > in a serial terminal configuration, why would you expect to see it > without one? That’s like troubleshooting a car’s braking system by > testing the air conditioning. > > The bug report explicitly states: > > "The issue is reproducible when using a serial terminal > configuration." > > > By failing to test under the relevant conditions, your results are > meaningless. You cannot disprove a bug by running an irrelevant test. > > 3. `tt_setonechar()` Is Used in sh-Mode > You claim: > > "It is not. There is no call to any of the tty functions to set > character-at-a-time behavior using those functions (there are several) > anywhere in the source except in the read builtin." > > > This is incorrect. The bug report explicitly documents that in sh-mode, > `tt_setonechar()` is involved in terminal attribute reinitialization in > a way that overwrites the user's explicitly set echoctl flag. Your > assertion that it is only used by `read -n` in standard Bash mode > ignores the fact that sh-mode has different handling, and in this case, > it is modifying termios settings when it should not. > > If your argument is that this behavior doesn’t exist, then please > provide an actual source-level explanation of why the reported behavior > does occur when Bash is invoked as `sh`. Otherwise, your statement is an > assumption, not a refutation. > > 4. Your Own `stty` Tests Contradict Your Conclusion > In your test: > ```sh > $ stty -echoctl > $ ls > $ sleep 5 > $ stty echoctl > $ ls^C > $ sleep 5 > ^C > ``` > All you’ve done here is show that Bash correctly respects `stty > -echoctl` in interactive mode when running as Bash. This does not > address the bug report’s claim that Bash-in-sh-mode improperly resets > termios flags in certain conditions. > > The fact that you manually toggled `stty echoctl` proves nothing about > whether Bash (when invoked as `sh`) is overriding the setting at > startup, which is the actual issue under discussion. > > 5. The Patch Demonstrates the Fix—You Just Ignored It > You stated: > > "It doesn't. The link you provided shows that Dennis built bash with > a minimal config and it works correctly." > > > Except that the patch explicitly shows that preserving ECHOCTL in > `tt_setonechar()` prevents the unwanted behavior. If it was not > necessary, why does the patch solve the problem? You haven’t engaged > with that at all. > > The proper way to challenge the patch would be to: > > Explain why the patch appears to work yet is unnecessary. > > Show the precise conditions under which Bash-in-sh-mode is NOT modifying > termios inappropriately. > > Demonstrate how an alternative explanation accounts for the observed > behavior. > > Instead, you dismissed it outright without addressing the actual fix. > > 6. "Why Not Show That?" > Your final question: > > "Are you telling me that this shell, when run as `sh`, behaves > differently? Why not show that?" > > > We DID show that. That’s literally what the bug report documents. What > we didn’t do was run an irrelevant test in the wrong environment and > then act as though that somehow disproves the issue. > > If you’re actually interested in verifying this issue properly: > 1. Use FreeBSD (since the bug report was submitted against a FreeBSD > build of Bash). > 2. Invoke Bash via the `sh` symlink to ensure it runs in sh-mode. > 3. Use a serial terminal setup to match the conditions under which the > bug manifests. > 4. Explicitly check the termios state befo
Re: "printf %d ''" should diagnose the empty string
a bit unrelated .. cheap numbers filter ..
gimme_num( ) { declare -n b=BASH_REMATCH\[1] ; local o m=[0-9,.] s=$n i t ;
t="(-?$m+)" ; unset -v o ; for n ; do unset -v i ; while [[ $n =~ $t ]] ;
do n=${n/"$b"} i= o+=$b$s ; done ; [[ -v i ]] && o+=$s ; done ; [[ -v o ]]
&& printf %s "$o" ; }
gimme_num ' ab3.44 cd---.99 ' cd cd 77.7.77
3.44
-.99
77.7.77
On Mon, Feb 10, 2025, 11:14 PM Phi Debian wrote:
> On Mon, Feb 10, 2025 at 11:10 PM Greg Wooledge wrote:
>
> >
> > hobbit:~$ phi 029
> > bash: ((: 029: value too great for base (error token is "029")
> > bash: ((: 029: value too great for base (error token is "029")
> >
> > So we come full circle.
> >
>
> Nope phi() is not mine and doesn't remove the error message, see my prev
> post about nuking $(()) syntax error
>
> 029 is not a number
>
> my latest post gives
>
> $ isanum 029 && echo y || echo n
> n
>
Re: "printf %d ''" should diagnose the empty string
ur subst version is best and fastest
, the my last version seems buggy
its to filter out numbers
.. just a bit related to the topic sorry ..
++ greets ++
On Tue, Feb 11, 2025, 10:23 AM Phi Debian wrote:
>
> Can follow that fast, the n-1 version gives
>
> gimme_num( ) { local y o m='[0-9,.]' s=$'\n' i t ; t="(-?$m+)" ; unset -v
> o ; for n ; do unset -v i ; while [[ $n =~ $t ]] ; do y=${BASH_REMATCH[1]}
> n=${n/"$y"} i= o+=$y$s ; done ; [[ -v i ]] && o+=$s ; done ; [[ -v o ]] &&
> printf %s "$o" ; }
> $ gimme_num 0x10 60#yo 0x10
> 0
> 10
>
> 60
>
> 0
> 10
>
> That can be streamlined as
> $ gimme_num2()
> { printf '%d\n' ${@//[^0-9]/ }
> }
> $ gimme_num2 0x10 60#yo 0x10
> 0
> 10
> 60
> 0
> 10
>
> The last version gives
>
> $ gimme_num( ) { local y o m='[0-9,.]' s=$'\n' i t ; t="(-?$m+)" ; unset
> -v o ; for n ; do i= ; if [[ $n =~ $t ]] ; then while [[ -v
> BASH_REMATCH[++i] ]] ; do o+=${BASH_REMATCH[i]}$s ; done ; fi ; [[ $i != 1
> ]] && o+=$s ; done ; [[ -v o ]] && printf %s "$o" ; }
> $ gimme_num 0x10 60#yo 0x10
> 0
>
> 60
>
> 0
>
> Dunno what use case I could do with that
>
>
>
Re: "printf %d ''" should diagnose the empty string
On Tue, Feb 11, 2025, 7:13 AM Phi Debian wrote:
>
>
> On Mon, Feb 10, 2025 at 11:46 PM microsuxx wrote:
>
>> a bit unrelated .. cheap numbers filter ..
>>
>> gimme_num( ) { declare -n b=BASH_REMATCH\[1] ; local o m=[0-9,.] s=$n i t
>> ;
>> t="(-?$m+)" ; unset -v o ; for n ; do unset -v i ; while [[ $n =~ $t ]] ;
>> do n=${n/"$b"} i= o+=$b$s ; done ; [[ -v i ]] && o+=$s ; done ; [[ -v o ]]
>> && printf %s "$o" ; }
>>
>> gimme_num ' ab3.44 cd---.99 ' cd cd 77.7.77
>>
>> 3.44
>> -.99
>>
>> 77.7.77
>>
>>
> Rejected
> $ gimme_num '0x10'
> 0x10xx
> $ gimme_num '64#yo'
> 64xx
> $ gimme_num '0x10'
> 0#yo10#yo#yo
>
> gimme_num should be renamed random_string()
>
how does it output strings .. ?
i mean i dont get ur outputs
1 it doesnt include # and @ etc
2 no hex etc yet , only numbers and dots / commas
gimme_num 0x10 60#yo 0x10
0
10
60
0
10
but i dont get ur outputs such as 0x10xx or 64xx or the other ..
>
Re: "printf %d ''" should diagnose the empty string
here updated faster version ..
gimme_num( ) { local y o m='[0-9,.]' s=$'\n' i t ; t="(-?$m+)" ; unset -v o
; for n ; do i= ; if [[ $n =~ $t ]] ; then while [[ -v BASH_REMATCH[++i] ]]
; do o+=${BASH_REMATCH[i]}$s ; done ; fi ; [[ $i != 1 ]] && o+=$s ; done ;
[[ -v o ]] && printf %s "$o" ; }
On Tue, Feb 11, 2025, 10:11 AM microsuxx wrote:
> ah , cool
>
> .. my bash 5.3 dev seems to have declare -n arr\[elem] while i think the
> old 5.2x that didnt work
>
> try plzz ..
>
> gimme_num( ) { local y o m='[0-9,.]' s=$'\n' i t ; t="(-?$m+)" ; unset -v
> o ; for n ; do unset -v i ; while [[ $n =~ $t ]] ; do y=${BASH_REMATCH[1]}
> n=${n/"$y"} i= o+=$y$s ; done ; [[ -v i ]] && o+=$s ; done ; [[ -v o ]] &&
> printf %s "$o" ; }
>
> On Tue, Feb 11, 2025, 10:07 AM Phi Debian wrote:
>
>>
>>
>> On Tue, Feb 11, 2025 at 9:37 AM microsuxx wrote:
>>
>>> how does it output strings .. ?
>>> i mean i dont get ur outputs
>>> 1 it doesnt include # and @ etc
>>> 2 no hex etc yet , only numbers and dots / commas
>>>
>>> gimme_num 0x10 60#yo 0x10
>>> 0
>>> 10
>>>
>>> 60
>>>
>>> 0
>>> 10
>>>
>>> but i dont get ur outputs such as 0x10xx or 64xx or the other ..
>>>
>>
>> I cut/pasted as is your code
>> $ gimme_num( ) { declare -n b=BASH_REMATCH\[1] ; local o m=[0-9,.] s=$n i
>> t ; t="(-?$m+)" ; unset -v o ; for n ; do unset -v i ; while [[ $n =~ $t ]]
>> ; do n=${n/"$b"} i= o+=$b$s ; done ; [[ -v i ]] && o+=$s ; done ; [[ -v o
>> ]] && printf %s "$o" ; }
>> $
>>
>> Then I run it with
>> $ echo $BASH_VERSION
>> 5.2.21(1)-release
>> $ shopt
>> autocd off
>> assoc_expand_once off
>> cdable_vars off
>> cdspell off
>> checkhash off
>> checkjobs off
>> checkwinsize on
>> cmdhist on
>> compat31 off
>> compat32 off
>> compat40 off
>> compat41 off
>> compat42 off
>> compat43 off
>> compat44 off
>> complete_fullquote on
>> direxpand off
>> dirspell off
>> dotglob off
>> execfail off
>> expand_aliases on
>> extdebug off
>> extglob off
>> extquote on
>> failglob off
>> force_fignore on
>> globasciiranges on
>> globskipdots on
>> globstar on
>> gnu_errfmt off
>> histappend off
>> histreedit off
>> histverify off
>> hostcomplete on
>> huponexit off
>> inherit_errexit off
>> interactive_comments on
>> lastpipe off
>> lithist on
>> localvar_inherit off
>> localvar_unset off
>> login_shell off
>> mailwarn off
>> no_empty_cmd_completion off
>> nocaseglob off
>> nocasematch off
>> noexpand_translation off
>> nullglob off
>> patsub_replacement on
>> progcomp on
>> progcomp_alias off
>> promptvars on
>> restricted_shell off
>> shift_verbose off
>> sourcepath on
>> varredir_close off
>> xpg_echo off
>>
>> And got this
>>
>> $ gimme_num 0x10 60#yo 0x10
>> 0x10xx60xx0x10xx$
>>
>>
Re: "printf %d ''" should diagnose the empty string
ah , cool
.. my bash 5.3 dev seems to have declare -n arr\[elem] while i think the
old 5.2x that didnt work
try plzz ..
gimme_num( ) { local y o m='[0-9,.]' s=$'\n' i t ; t="(-?$m+)" ; unset -v o
; for n ; do unset -v i ; while [[ $n =~ $t ]] ; do y=${BASH_REMATCH[1]}
n=${n/"$y"} i= o+=$y$s ; done ; [[ -v i ]] && o+=$s ; done ; [[ -v o ]] &&
printf %s "$o" ; }
On Tue, Feb 11, 2025, 10:07 AM Phi Debian wrote:
>
>
> On Tue, Feb 11, 2025 at 9:37 AM microsuxx wrote:
>
>> how does it output strings .. ?
>> i mean i dont get ur outputs
>> 1 it doesnt include # and @ etc
>> 2 no hex etc yet , only numbers and dots / commas
>>
>> gimme_num 0x10 60#yo 0x10
>> 0
>> 10
>>
>> 60
>>
>> 0
>> 10
>>
>> but i dont get ur outputs such as 0x10xx or 64xx or the other ..
>>
>
> I cut/pasted as is your code
> $ gimme_num( ) { declare -n b=BASH_REMATCH\[1] ; local o m=[0-9,.] s=$n i
> t ; t="(-?$m+)" ; unset -v o ; for n ; do unset -v i ; while [[ $n =~ $t ]]
> ; do n=${n/"$b"} i= o+=$b$s ; done ; [[ -v i ]] && o+=$s ; done ; [[ -v o
> ]] && printf %s "$o" ; }
> $
>
> Then I run it with
> $ echo $BASH_VERSION
> 5.2.21(1)-release
> $ shopt
> autocd off
> assoc_expand_once off
> cdable_vars off
> cdspell off
> checkhash off
> checkjobs off
> checkwinsize on
> cmdhist on
> compat31 off
> compat32 off
> compat40 off
> compat41 off
> compat42 off
> compat43 off
> compat44 off
> complete_fullquote on
> direxpand off
> dirspell off
> dotglob off
> execfail off
> expand_aliases on
> extdebug off
> extglob off
> extquote on
> failglob off
> force_fignore on
> globasciiranges on
> globskipdots on
> globstar on
> gnu_errfmt off
> histappend off
> histreedit off
> histverify off
> hostcomplete on
> huponexit off
> inherit_errexit off
> interactive_comments on
> lastpipe off
> lithist on
> localvar_inherit off
> localvar_unset off
> login_shell off
> mailwarn off
> no_empty_cmd_completion off
> nocaseglob off
> nocasematch off
> noexpand_translation off
> nullglob off
> patsub_replacement on
> progcomp on
> progcomp_alias off
> promptvars on
> restricted_shell off
> shift_verbose off
> sourcepath on
> varredir_close off
> xpg_echo off
>
> And got this
>
> $ gimme_num 0x10 60#yo 0x10
> 0x10xx60xx0x10xx$
>
>
Re: Manual entry for !!:$
!!:$ null !$ null $_ echo On Sat, Jan 18, 2025, 7:29 AM Martin Schulte wrote: > Hello, > > in 9.3.2 of https://www.gnu.org/software/bash/manual/bash.html we find: > > !!:$ designates the last argument of the preceding command. This may be > shortened to !$. > > Shouldn't this be "the last word" instead of the "the last argument": > > $ echo hello > /dev/null > $ echo !!:$ > echo /dev/null > /dev/null > > 5.2 states (correctly from my point of view): > > _ ... Subsequently, expands to the last argument to the previous simple > command executed in the foreground, after expansion. ... > > $ echo hello > /dev/null > $ echo $_ > hello > > Best regards, > > Martin > >
Re: printf width format specifier doesn't work when assigned
~ $ set -f
~ $ foo=$(printf "%*s\n" 80 " " | tr " " "*") ; echo $foo
~ $ printf -v v '%*s' 200 ' ' ; v=${v// /\*} ; echo $v
On Sat, Jan 25, 2025, 2:41 PM Ross wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-
> frame-pointer -flto=auto -ffat-lto-objects -fstack-protector-strong -
> fstack-clash-protection -Wformat -Werror=format-security -fcf-
> protection -Wall
> uname output: Linux X220-Bravo 6.8.0-51-generic #52-Ubuntu SMP
> PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64
> GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.2
> Patch Level: 21
> Release Status: release
>
> Description:
> From the command line
> printf "%*s\n" 80 " " | tr " " "*"
> does just what I'd expect generating a banner line of asterisks.
>
> However:
> foo=$(printf "%*s\n" 80 " " | tr " " "*")
> echo $foo
> acts very differently; it seems to perform ls or something similar.
>
> The same occurs with the more standard printf "%80s" form.
>
> Repeat-By:
> As above.
>
> Fix:
> Unknown.
>
>
>
Re: printf width format specifier doesn't work when assigned
the \* to * works also
leftover of testing
.. needs set -f
On Sat, Jan 25, 2025, 3:34 PM microsuxx wrote:
> ~ $ set -f
> ~ $ foo=$(printf "%*s\n" 80 " " | tr " " "*") ; echo $foo
>
>
>
> ~ $ printf -v v '%*s' 200 ' ' ; v=${v// /\*} ; echo $v
>
>
> On Sat, Jan 25, 2025, 2:41 PM Ross wrote:
>
>>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-
>> frame-pointer -flto=auto -ffat-lto-objects -fstack-protector-strong -
>> fstack-clash-protection -Wformat -Werror=format-security -fcf-
>> protection -Wall
>> uname output: Linux X220-Bravo 6.8.0-51-generic #52-Ubuntu SMP
>> PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64
>> GNU/Linux
>> Machine Type: x86_64-pc-linux-gnu
>>
>> Bash Version: 5.2
>> Patch Level: 21
>> Release Status: release
>>
>> Description:
>> From the command line
>> printf "%*s\n" 80 " " | tr " " "*"
>> does just what I'd expect generating a banner line of asterisks.
>>
>> However:
>> foo=$(printf "%*s\n" 80 " " | tr " " "*")
>> echo $foo
>> acts very differently; it seems to perform ls or something similar.
>>
>> The same occurs with the more standard printf "%80s" form.
>>
>> Repeat-By:
>> As above.
>>
>> Fix:
>> Unknown.
>>
>>
>>
Re: 'read' sometimes truncates trailing field delimiter
On Mon, Jan 13, 2025, 4:46 AM Greg Wooledge wrote: > On Mon, Jan 13, 2025 at 08:42:39 +0700, Robert Elz wrote: > > It is unexpected, because users believe (from other experience) > > that the delimiters separate fields, but in sh they don't, they > > terminate fields. > > At the risk of going a bit off topic, may I ask *why* the shell does > that? Were there any files or data stream conventions in common use > in the 1970s that would have prompted that design decision? > > Files like /etc/group and /etc/passwd certainly don't conform to > that data format, so the sh behavior definitely didn't arise from either > of those. > > The only realistic example I can think of would be something like > printf '%s\0' "$@" to serialize the positional parameters into a stream > i learned , \0 data is the only >general< stdin stdout separation way or similiar self developed custom delimiters stuff no idea about all the texts discussed here .. of NUL-terminated C strings. But the Bourne shell doesn't have the means > of reading such a stream (it has no read -d '', and you certainly can't > use NUL as an IFS character), so I don't think that was what Mr. Bourne > had in mind either. (Not to mention, the Bourne shell didn't have printf > either.) > > It just feels like the shell is trying to do a job that nobody actually > wants done. > >
Re: 'read' sometimes truncates trailing field delimiter
does the output @ https://0x0.st/8-Fv.txt
make it into the race
by cmd @ https://0x0.st/8-Ft.txt
i can be as well fully off the topic
excuse me then , and plz lemme know ..
On Mon, Jan 13, 2025, 9:03 AM Félix Hauri wrote:
> Le Sun, Jan 12, 2025 at 04:10:03PM -0500, Chet Ramey a écrit :
> >
> > This is a simplified version how it works: after you remove leading
> > and trailing IFS whitespace, you read individual fields from the input
> > using the characters in IFS as field terminators.
>
> > If you get to the last variable and find a field terminator (in this
> > case, the end of input qualifies as a field terminator), you check
> > whether there is additional input.
>
> > If there is, you just end the process there and assign whatever input
> > followed the previous delimiter you found to the last variable,
> > delimiters included. If not, the field is terminated and assigned to
> > the last variable.
>
>
> Re-reading man page and this discussion, I thing either this variable is
> wrongly named "IFS", as `S` stand for "separator", either the man page
> paragraph regarding "IFS" is something light.
>
> Btw, the command "mapfile" (readarray) seem more suitable** than "read" for
> splitting an array on delimiter. (** constant)
>
>$ printf ' %-15s %-30s%s\n' String by\ Read{,Array};while IFS= read -r
> line;
>do
> IFS=: read -r _k _v1 _v2 <<<"$line"
> readarray -td: array < <(printf %s "$line");
> k="${array[0]}" v1="${array[1]}";
> IFS=:; v2=${array[*]:2}; IFS=$' \t\n';
> printf " %-15s k=%-3s v1=%-4s v2=%-11s k=%-3s v1=%-4s
> v2=%-11s\n" \
> "${line@Q}" "${_k@Q}" "${_v1@Q}" "${_v2@Q}" \
> "${k@Q}" "${v1@Q}" "${v2@Q}";
> done < <(
> printf '%s\n' \
>k{:v1{:v2{:v3{:{:{:,},},},:{:{:,},},},:{:{:,},},},:{:{:,},},} )
>
> String by Read by ReadArray
> 'k:v1:v2:v3:::' k='k' v1='v1' v2='v2:v3:::' k='k' v1='v1'
> v2='v2:v3::'
> 'k:v1:v2:v3::' k='k' v1='v1' v2='v2:v3::'k='k' v1='v1'
> v2='v2:v3:'
> 'k:v1:v2:v3:' k='k' v1='v1' v2='v2:v3:' k='k' v1='v1'
> v2='v2:v3'
> 'k:v1:v2:v3'k='k' v1='v1' v2='v2:v3' k='k' v1='v1'
> v2='v2:v3'
> 'k:v1:v2:::'k='k' v1='v1' v2='v2:::' k='k' v1='v1' v2='v2::'
>
> 'k:v1:v2::' k='k' v1='v1' v2='v2::' k='k' v1='v1' v2='v2:'
>
> 'k:v1:v2:' k='k' v1='v1' v2='v2' k='k' v1='v1' v2='v2'
>
> 'k:v1:v2' k='k' v1='v1' v2='v2' k='k' v1='v1' v2='v2'
>
> 'k:v1:::' k='k' v1='v1' v2='::' k='k' v1='v1' v2=':'
>
> 'k:v1::'k='k' v1='v1' v2='' k='k' v1='v1' v2=''
>
> 'k:v1:' k='k' v1='v1' v2='' k='k' v1='v1' v2=''
>
> 'k:v1' k='k' v1='v1' v2='' k='k' v1='v1' v2=''
>
> 'k:::' k='k' v1='' v2='' k='k' v1='' v2=''
>
> 'k::' k='k' v1='' v2='' k='k' v1='' v2=''
>
> 'k:'k='k' v1='' v2='' k='k' v1='' v2=''
>
> 'k' k='k' v1='' v2='' k='k' v1='' v2=''
>
>
>
>
>
>
>
>
>
> --
> Félix Hauri -- http://www.f-hauri.ch
>
>
Re: Another undo list UAF
those bugs have old lib versions around .. On Fri, Jan 17, 2025, 3:32 PM Chet Ramey wrote: > On 1/15/25 4:08 PM, Grisha Levit wrote: > > Another undo list UAF. Related, I think, to edit-and-execute-command. > > > > HISTFILE= INPUTRC=/ bash --norc -in <<< $' \n\cP \cN\cP\cU\cX\cE\n\e<' > > I can't reproduce this on macOS. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists
to use ~ as file .. '~' n "~" or ./~ On Wed, Feb 12, 2025, 5:21 PM Andrés Rodríguez Reina wrote: > Subject: [Suggestion] Add warning/error when using the tilde expansion in > a folder where the tile-named file/folder exists > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security > uname output: Linux ltarrr 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu > Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > Description: > Due to a mistake in coding a script, a folder named '~' was > generated. An unexperienced bash user issued the command "rm -rf ~" by > mistake, intending to delete the '~' folder, but this resulted in deleting > 150GB+ of data at their home directory. > In my opinion, it would be useful to have a warning be issued when > in interactive mode, when at the current working directory a file/folder > named '~' exists, and a command with a parameter starting with ~ is used > (which will produce tilde expansion). > > Repeat-By: > Create a file/folder named '~': mkdir '~' > Try to delete it with a bogus command (DO NOT EXECUTE): rm -rf ~ > > Fix: > When in interactive mode and when a suitable flag is activated, an > error should appear. For example: > the home path to avoid ambiguity.> > > Thank you for your time, > Andres R >
Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists
or \~ On Wed, Feb 12, 2025, 9:05 PM microsuxx wrote: > to use ~ as file .. > > '~' n "~" > or ./~ > > On Wed, Feb 12, 2025, 5:21 PM Andrés Rodríguez Reina > wrote: > >> Subject: [Suggestion] Add warning/error when using the tilde expansion in >> a folder where the tile-named file/folder exists >> >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -g -O2 >> -fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=. -fstack-protector-strong >> -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security >> uname output: Linux ltarrr 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu >> Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 5.0 >> Patch Level: 17 >> Release Status: release >> >> Description: >> Due to a mistake in coding a script, a folder named '~' was >> generated. An unexperienced bash user issued the command "rm -rf ~" by >> mistake, intending to delete the '~' folder, but this resulted in deleting >> 150GB+ of data at their home directory. >> In my opinion, it would be useful to have a warning be issued >> when in interactive mode, when at the current working directory a >> file/folder named '~' exists, and a command with a parameter starting with >> ~ is used (which will produce tilde expansion). >> >> Repeat-By: >> Create a file/folder named '~': mkdir '~' >> Try to delete it with a bogus command (DO NOT EXECUTE): rm -rf ~ >> >> Fix: >> When in interactive mode and when a suitable flag is activated, >> an error should appear. For example: >> > the home path to avoid ambiguity.> >> >> Thank you for your time, >> Andres R >> >
Re: history writes to process substitution but errors reading it
is that if fifo or if nonormal file ..
.. is that another story from history .. ?
that it doesnt accept them ..
On Fri, Feb 14, 2025, 1:36 PM Greg Wooledge wrote:
> On Fri, Feb 14, 2025 at 05:19:48 -0600, MacBeth wrote:
> > On Fri, Feb 14, 2025 at 4:31 AM MacBeth
> wrote:
> > > # fails:
> > > $ history -r <(echo 'echo bad')
> >
> > Unless the reason is due to the file seek issue as described here...?
> > https://unix.stackexchange.com/a/164109
>
> hobbit:~$ echo ': testing file y' > y
> hobbit:~$ strace bash -c 'history -r y'
> [...]
> openat(AT_FDCWD, "y", O_RDONLY) = 3
> newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=17, ...}, AT_EMPTY_PATH)
> = 0
> read(3, ": testing file y\n", 17) = 17
> close(3)= 0
> [...]
>
> hobbit:~$ strace bash -c 'history -r <(echo ": testing procsub")'
> [...]
> openat(AT_FDCWD, "/dev/fd/63", O_RDONLY) = 3
> newfstatat(3, "", {st_mode=S_IFIFO|0600, st_size=0, ...}, AT_EMPTY_PATH) =
> 0
> close(3)= 0
> close(63) = 0
> [...]
>
> Looks like it never even tries to read the bytes from the procsub. It
> checks the file's type, sees S_IFIFO, and silently ignores it.
>
> You'd think it would at least give a warning.
>
>
Re: history writes to process substitution but errors reading it
it looks me cause such as it isnt a file , yes .. On Fri, Feb 14, 2025, 12:20 PM MacBeth wrote: > On Fri, Feb 14, 2025 at 4:31 AM MacBeth wrote: > > > > Ummm, isn't this supposed to work? I'm guessing there's a technical > > reason why it doesn't...? > > > > # fails: > > $ history -r <(echo 'echo bad') > > > > Unless the reason is due to the file seek issue as described here...? > https://unix.stackexchange.com/a/164109 > > Seems like this issue would be good to be warned about in the manual, > as I don't think it is. > >
Re: How to fix this
what u wanna fix on it On Mon, Feb 24, 2025, 3:13 PM rjuliuscezar--- via Bug reports for the GNU Bourne Again SHell wrote: > usage: command-not-found > > ╭─u0_a440@localhost ~ > ╰─🍄💨➤➤ > >
Re: Unexpected $BASH_COMMAND after error in subshell
++bugfixes++ On Wed, Feb 26, 2025, 3:15 PM Chet Ramey wrote: > On 2/23/25 12:20 PM, Max Bowsher wrote: > > > Bash Version: 5.2 > > Patch Level: 37 > > Release Status: release > > > > Description: > > > > When using $BASH_COMMAND in an EXIT trap to tell the user what failed, I > > came across a problem where errors in subshells would instead implicate > the > > command immediately before the subshell, instead of the subshell itself. > > Thanks for the report. The subshell updates BASH_COMMAND, but not the > parent. It's an easy change to make. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
Re: Possible bug for nested curly brace expansion
{0} is no expansion
{0,} is
it must be 2+
On Thu, Mar 6, 2025, 7:40 PM Trond Endrestøl via Bug reports for the GNU
Bourne Again SHell wrote:
> $ bash --version
> GNU bash, version 5.2.37(0)-release (amd64-portbld-freebsd14.1)
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm2{0}
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0,1}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm20
> devel/llvm21
>
> I didn't expect the curly braces at the end of the first example. It
> should produce devel/llvm20 in my opinion. Everything is fine as long
> as the number of elements are > 1.
>
> csh(1) in FreeBSD gives the expected expansion for both examples:
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm20
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0,1}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm20
> devel/llvm21
>
> --
> --
> Trond Endrestøl | trond.endres...@ximalas.info
> Member of ACM, NAS, NUUG | FreeBSD 14.2-S & Alpine 2.26
>
Re: ;exit in bash history causes bash to exit
when bash reads exit cmd it will exit so bash reads rc and exits .. also .. u may have a ';exit' alias .. On Tue, Mar 25, 2025, 22:15 microsuxx wrote: > dude if u tell bash to exit it will exit .. > > On Tue, Mar 25, 2025, 20:41 Ethan Gascoigne wrote: > >> From: ethan >> To: bug-bash@gnu.org >> Subject: ;exit in bash history causes bash to exit >> >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt >> -fexceptions -Wp,-D_FORTIFY_SOUR> >> uname output: Linux eLaptop 6.13.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, >> 23 Mar 2025 17:17:30 + x86_64 GNU> >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 5.2 >> Patch Level: 37 >> Release Status: release >> >> Description: >> Having ";exit" as the last entry in .bash_history, causes bash >> to immediately exit when loading >> Note: Also appears to happen with alises. For example I have >> `q` aliased to `exit`, and `;q` causes > >> >> Repeat-By: >> Open a terminal with bash as the shell >> Type `;exit` >> Re-open the terminal, it will immediately close >> >>
Re: ;exit in bash history causes bash to exit
dude if u tell bash to exit it will exit .. On Tue, Mar 25, 2025, 20:41 Ethan Gascoigne wrote: > From: ethan > To: bug-bash@gnu.org > Subject: ;exit in bash history causes bash to exit > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt > -fexceptions -Wp,-D_FORTIFY_SOUR> > uname output: Linux eLaptop 6.13.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, > 23 Mar 2025 17:17:30 + x86_64 GNU> > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 > Patch Level: 37 > Release Status: release > > Description: > Having ";exit" as the last entry in .bash_history, causes bash > to immediately exit when loading > Note: Also appears to happen with alises. For example I have > `q` aliased to `exit`, and `;q` causes > > > Repeat-By: > Open a terminal with bash as the shell > Type `;exit` > Re-open the terminal, it will immediately close > >
Re: ;exit in bash history causes bash to exit
ah bash history file .. .. yea i tried , bash dev doesnt segfault or anything , with it on a line and without an ending newline warm greetings .. :)) On Tue, Mar 25, 2025, 22:56 Greg Wooledge wrote: > On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote: > > when bash reads exit cmd it will exit > > so bash reads rc and exits .. > > also .. u may have a ';exit' alias .. > > The claim is that the ;exit appears in .bash_history (not .bashrc) > and that this somehow causes a new instance of bash to exit. > > I doubt anyone will be able to reproduce this. We're almost certainly > going to need more information from Ethan -- the contents of the > relevant dot files, for example. > >
Re: ;exit in bash history causes bash to exit
yea make bug report .. in my experience , such bash codes on github have very low code quality .. peace .. ++ On Wed, Mar 26, 2025, 15:09 Ethan Gascoigne wrote: > I do have an alias with `&& exit` in it, but removing that alias > doesn't get rid of the bug. I've tested it on another system (Xubuntu > 24.04, stock install), and the issue didn't occur. > > Narrowed it down to the line `eval "$(fasd --init auto)"` in my > .bashrc. Must be some kindof bug with fasd > (https://github.com/whjvenyl/fasd). Any idea how fasd could cause > `;exit` to be interpreted as a valid command? Running `alias exit` > shows that it's not aliased to anything. > > Weird that fasd causes `;exit` to be a valid command, and also that it > causes bash to execute it when loading if it's the last thing in the > history file. I'll raise a bug report on the fasd GitHub. Apologies > for the erroneous report. > > Cheers, > Ethan > > > > On Tue, 25 Mar 2025 at 20:24, Martin Schulte > wrote: > > > > Hello Ethan, > > > > I can't reproduce the problem: > > > > > Repeat-By: > > > Open a terminal with bash as the shell > > > Type `;exit` > > > > This results in > > > > bash: syntax error near unexpected token `;' > > > > but not in closing the shell. > > > > > Re-open the terminal, it will immediately close > > > > Is there maybe something broken in your setup? > > > > Best regards, > > > > Martin > >
Re: Bash skips empty lines when reading history file in multiline mode
one small addition , <<'foo' ( with quotes is used ) .. .. should tell bash expliciply preserve data .. On Mon, Apr 7, 2025, 23:51 microsuxx wrote: > i dunno what lithist is , but remaining data one to one is a big bug thats > gotta be fixed > its like u write foo "$1" "$2" and it sends foo $1 $2 > .. if data , in case heredoc content , which is highly underrated and > underused , is not remained .. its nothing else than a big broken cmd > plz fixx > greets++ ur microsucker .. > > On Mon, Apr 7, 2025, 22:34 Chet Ramey wrote: > >> On 4/4/25 4:18 PM, Jens Schmidt wrote: >> >> > [bashbug output manually adapted to real version ...] >> > Bash Version: 5.3 >> > Commit: a6767763de5e7859107711b166a64a9e4a77a8ae >> > Release Status: compiled from recent devel branch >> > >> > >> > Description: >> >Bash skips empty lines when reading history file in multiline mode. >> >> This is a problem even if lithist isn't set -- it's not uncommon to have >> blank lines in here-documents. >> >> But do you really think people want blank history entries even with >> lithist >> set? How about history processing blank lines as part of the command after >> it reads the first non-blank line? >> >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >> >
Re: Bash skips empty lines when reading history file in multiline mode
i dunno what lithist is , but remaining data one to one is a big bug thats gotta be fixed its like u write foo "$1" "$2" and it sends foo $1 $2 .. if data , in case heredoc content , which is highly underrated and underused , is not remained .. its nothing else than a big broken cmd plz fixx greets++ ur microsucker .. On Mon, Apr 7, 2025, 22:34 Chet Ramey wrote: > On 4/4/25 4:18 PM, Jens Schmidt wrote: > > > [bashbug output manually adapted to real version ...] > > Bash Version: 5.3 > > Commit: a6767763de5e7859107711b166a64a9e4a77a8ae > > Release Status: compiled from recent devel branch > > > > > > Description: > >Bash skips empty lines when reading history file in multiline mode. > > This is a problem even if lithist isn't set -- it's not uncommon to have > blank lines in here-documents. > > But do you really think people want blank history entries even with lithist > set? How about history processing blank lines as part of the command after > it reads the first non-blank line? > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: Heredoc with a multiline delimiter
++ On Sun, Mar 16, 2025, 12:10 AM MacBeth wrote: > On Sat, Mar 15, 2025 at 12:33 PM Greg Wooledge wrote: > > On Sat, Mar 15, 2025 at 16:14:00 +, Nikola Novak via Bug reports for > the GNU Bourne Again SHell wrote: > > > How do you end the heredoc with a multiline delimiter such as the > following: > > > > > > cat << "a > > > b" > > > > You don't. > > > > However you could fake it, by including backslashes in the delimiter, > which would allow literal newlines, but bash would ignore them as they > are escape sequences. So they wouldn't actually be a part of the > delimiter from bash's perspective, but merely visually and accepted > from the literal input. > > $ cat < $ EOF > $ hello > $ goodbye > $ EOT\ > $ EOF > hello > goodbye > $ > >
Re: /dev/tcp feature request...
[[ -d /proc/"$!" ]] On Tue, Apr 8, 2025, 16:33 Andreas Schwab wrote: > On Apr 08 2025, MacBeth wrote: > > > while ((dur /dev/null; do > > You can use kill -0 $! to check if the process still exists. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." > >
Re: /dev/tcp feature request...
same error as eof i'd say .. On Fri, Apr 11, 2025, 01:53 A. James Lewis wrote: > I'm not quite sure about that, I would be trying to get back the file > descriptor to use for a period and then close it... so if it fails to > open, then I don't know if "redirection error" makes sense, but then > again, I'm not sure what would the correct error be. > > Certainly I would just be checking for a successful exit code from > opening the connection > > It makes me wonder what the existing error message is, because it > /does/ time out currently... but only after 10 minutes, which I think > is the kernel giving up, and thus forcing the failure. > > My use case for reference, is trying to connect to a primary server, > but waiting only 2-5 seconds before giving up and trying a secondary... > as my goal is to achieve a connection as quickly as possible, but > ideally waiting not waiting any longer than 5 seconds if the primary > server is down and I must move on to the secondary. > > James > > > On Thu, 2025-04-10 at 15:14 -0400, Chet Ramey wrote: > > On 4/7/25 6:24 PM, A. James Lewis wrote: > > > I've not been around this mailing list all too long, so I don't > > > know if > > > this has been debated before, but I have always attempted to avoid > > > using external programs where functionality within bash can meet a > > > requirement. Doing this allows my scripts to be more reliable, and > > > not > > > depend on those external tools being installed... > > > > > > I have however found it extremely frustrating to open TCP > > > connections > > > via /dev/tcp, because there appears to be no way to control the > > > timeout! This means I cannot "try one server and move on to the > > > next > > > if it's not responding" etc... the default timeout is quite long, > > > so > > > even a simple script to check a list of servers for a response on a > > > given port is problematic. > > > > > > Is this a feature which might be possible in a future version of > > > Bash? > > > > I'll look at it for a future version. One question: do you think a > > connection timeout should be considered a redirection error? > > > > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > >``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, UTech, CWRUc...@case.edu > > http://tiswww.cwru.edu/~chet/ > >
Re: /dev/tcp feature request...
++ On Fri, Apr 11, 2025, 17:21 Chet Ramey wrote: > On 4/11/25 11:03 AM, microsuxx wrote: > > same error as eof i'd say .. > > No. The file descriptor is invalid. There is a difference between a read > error (-1/EINVAL) and EOF (0). > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: Bash shell uses wrong language
++ On Mon, Apr 14, 2025, 16:46 Chet Ramey wrote: > On 4/13/25 11:37 AM, microsuxx wrote: > > seems to cycle between lc : parts one loose .. > > No, these are all translated strings. > > >> hobbit:~$ LANGUAGE=en_US:es_ES bash --version > >> GNU bash, versión 5.2.15(1)-release (x86_64-pc-linux-gnu) > > Note the accented `o'. > > >> Copyright (C) 2022 Free Software Foundation, Inc. > > This string was left unchanged by the translation team, at least in the > po file I shipped with bash-5.2. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
Re: Bash shell uses wrong language
seems to cycle between lc : parts one loose .. On Sun, Apr 13, 2025, 16:46 Greg Wooledge wrote: > On Sun, Apr 13, 2025 at 16:06:46 +0200, Kaulkwappe wrote: > > > bash --version > > > GNU bash, Version 5.2.32(1)-release (x86_64-redhat-linux-gnu) > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > Lizenz GPLv3+: GNU GPL Version 3 oder jünger < > http://gnu.org/licenses/gpl.html> > > > > > > Dies ist freie Software. Sie darf verändert und verteilt werden. > > > Es wird keine Garantie gewährt, soweit das Gesetz es zulässt. > > > > env | grep LANG > > LANGUAGE=en_US:en_US:en_US:de > > LANG=en_US.UTF-8 > > This seems more like a libc bug than a bash bug, but for the record, I > can reproduce this on Debian 12: > > hobbit:~$ env | grep LANG > LANG=en_US.utf8 > hobbit:~$ locale -a > C > C.utf8 > en_US.utf8 > es_ES.utf8 > POSIX > hobbit:~$ LANGUAGE=en_US:es_ES bash --version > GNU bash, versión 5.2.15(1)-release (x86_64-pc-linux-gnu) > Copyright (C) 2022 Free Software Foundation, Inc. > Licencia GPLv3+: GPL de GNU versión 3 o posterior < > http://gnu.org/licenses/gpl.html> > > Esto es software libre, es libre para modificar y redistribuirlo. > No hay NINGUNA GARANTÍA, a la extensión permitida por la ley. > >
