Re: some unknown bug, says : command not found
i completly dunno how to fix, it looks me like a bash bug due to unconsitency, .., i can try later on wsl2 on win11 debian, ..but ive had yet a lots of couple of inconsistency bugs like this, also to early startup symlink related i dont remember exactly anymore On Tue, Nov 2, 2021, 06:07 Alex fxmbsw7 Ratchev wrote: > .. regarding a $notset <( .. wouldnt that display in set -x on that line, > rather when the cat or gawk is ran > > On Tue, Nov 2, 2021, 06:03 Alex fxmbsw7 Ratchev wrote: > >> i dont see the 63, its inside that tho >> >> i post the code, as i saw its fairly short, 'xbl' file >> the tgz with required awks and support files is also sent >> >> but anyway in the xbl the affected part are the cat or kopi.gawk if parts >> inside $xblpp <( here ) >> >> $xblpp is either cat or . >> cat for 'display me the code' and defaultly . for 'source the code, not >> display' >> $t and $t2 are just stamps, as seen in my set -x post >> >> i think this error came up recently just, it happens when i . xbl too >> new bash seasion sources it right without err, i never seen this err >> before too >> bash 5.1.8 debian release >> >> i think its some bug.. what else could it be, .. new bash sessions source >> it right, also before this err really wasnt, not that i tried . script >> instead of new bash sessions much >> >> .. >> >> On Mon, Nov 1, 2021, 23:08 Andreas Kusalananda Kähäri < >> andreas.kah...@abc.se> wrote: >> >>> On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: >>> > Date:Mon, 1 Nov 2021 12:03:48 -0400 >>> > From:Greg Wooledge >>> > Message-ID: >>> > >>> > | > bash: : command not found >>> > | > bash: : command not found >>> > | >>> > | Because this is you, I can't be sure whether you are correctly >>> pasting >>> > | the output from your terminal into email, >>> > >>> > Actually, because it is him, it is more likely that he has "cat" >>> aliased >>> > to ' ' somehow, since he loves aliases so much. >>> > >>> > kre >>> > >>> >>> Looking at their trace output, the thing that causes the error is >>> >>> '' /dev/fd/63 >>> >>> The /dev/fd/63 bit is probably from a process substitution. >>> >>> What causes the '' is anyone's guess, and mine is that it's simply a >>> variable that happens to be unset or empty (possibly due to a mistyping >>> in its name?) >>> >>> $ "$my_thnig" <( [[ -s "$pathname" ]] && cat -- "$pathname" ) >>> bash: : command not found >>> >>> >>> >>> -- >>> Andreas (Kusalananda) Kähäri >>> SciLifeLab, NBIS, ICM >>> Uppsala University, Sweden >>> >>> . >>> >>>
Re: some unknown bug, says : command not found
bash xbl 0 exit // 22713s old , static means it exited 0 on old shell . xbl bash: : command not found 0 exit // 22775s old , static ( it didnt exit on that cmd not found ) On Tue, Nov 2, 2021, 09:19 Alex fxmbsw7 Ratchev wrote: > i completly dunno how to fix, it looks me like a bash bug due to > unconsitency, .., i can try later on wsl2 on win11 debian, ..but ive had > yet a lots of couple of inconsistency bugs like this, also to early startup > symlink related i dont remember exactly anymore > > On Tue, Nov 2, 2021, 06:07 Alex fxmbsw7 Ratchev wrote: > >> .. regarding a $notset <( .. wouldnt that display in set -x on that line, >> rather when the cat or gawk is ran >> >> On Tue, Nov 2, 2021, 06:03 Alex fxmbsw7 Ratchev >> wrote: >> >>> i dont see the 63, its inside that tho >>> >>> i post the code, as i saw its fairly short, 'xbl' file >>> the tgz with required awks and support files is also sent >>> >>> but anyway in the xbl the affected part are the cat or kopi.gawk if >>> parts inside $xblpp <( here ) >>> >>> $xblpp is either cat or . >>> cat for 'display me the code' and defaultly . for 'source the code, not >>> display' >>> $t and $t2 are just stamps, as seen in my set -x post >>> >>> i think this error came up recently just, it happens when i . xbl too >>> new bash seasion sources it right without err, i never seen this err >>> before too >>> bash 5.1.8 debian release >>> >>> i think its some bug.. what else could it be, .. new bash sessions >>> source it right, also before this err really wasnt, not that i tried . >>> script instead of new bash sessions much >>> >>> .. >>> >>> On Mon, Nov 1, 2021, 23:08 Andreas Kusalananda Kähäri < >>> andreas.kah...@abc.se> wrote: >>> On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: > Date:Mon, 1 Nov 2021 12:03:48 -0400 > From:Greg Wooledge > Message-ID: > > | > bash: : command not found > | > bash: : command not found > | > | Because this is you, I can't be sure whether you are correctly pasting > | the output from your terminal into email, > > Actually, because it is him, it is more likely that he has "cat" aliased > to ' ' somehow, since he loves aliases so much. > > kre > Looking at their trace output, the thing that causes the error is '' /dev/fd/63 The /dev/fd/63 bit is probably from a process substitution. What causes the '' is anyone's guess, and mine is that it's simply a variable that happens to be unset or empty (possibly due to a mistyping in its name?) $ "$my_thnig" <( [[ -s "$pathname" ]] && cat -- "$pathname" ) bash: : command not found -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: some unknown bug, says : command not found
On Tue, Nov 02, 2021 at 04:52:24AM +0100, Alex fxmbsw7 Ratchev wrote: > to answer around what was written, i dont have a cat alias > > but what mr andreas wrote seems much similiar to what i do, process sub.. > ill check the vars carefully but i dont get it fully unicorn:~$ bash unicorn:~$ $xyz <( true ) bash: /dev/fd/63: Permission denied unicorn:~$ "$xyz" <( true ) bash: : command not found > but, on your all tries to produce command not found, can u set -x the > tries, .. in mine it shows cat ... then command not found, like the > cat is gone somehow > means does yours produce a + cat ( or cmd ) and then just display command > not found unicorn:~$ bash unicorn:~$ set -x unicorn:~$ "$xyz" <( cat /dev/null ) + '' /dev/fd/63 ++ cat /dev/null bash: : command not found I don't know what else to tell you. Your customized environment is so ridiculously convoluted that NOBODY understands it, not even you. Either this is helpful, or not. I don't think you're going to get any better results from help-bash or bug-bash than this. In any case, I'm 99% sure this is not a bug in bash -- only in one of your files.
Re: some unknown bug, says : command not found
but how why or to fix thers the code, thers the set -x parts ++ xblpp=. .. ++ '' /dev/fd/63 On Tue, Nov 2, 2021, 13:49 Alex fxmbsw7 Ratchev wrote: > i dont have "$var" <( sub ) i have $var <( sub ) > else it makes sense > > On Tue, Nov 2, 2021, 13:42 Greg Wooledge wrote: > >> On Tue, Nov 02, 2021 at 04:52:24AM +0100, Alex fxmbsw7 Ratchev wrote: >> > to answer around what was written, i dont have a cat alias >> > >> > but what mr andreas wrote seems much similiar to what i do, process >> sub.. >> > ill check the vars carefully but i dont get it fully >> >> unicorn:~$ bash >> unicorn:~$ $xyz <( true ) >> bash: /dev/fd/63: Permission denied >> unicorn:~$ "$xyz" <( true ) >> bash: : command not found >> >> > but, on your all tries to produce command not found, can u set -x the >> > tries, .. in mine it shows cat ... then command not found, like the >> > cat is gone somehow >> > means does yours produce a + cat ( or cmd ) and then just display >> command >> > not found >> >> unicorn:~$ bash >> unicorn:~$ set -x >> unicorn:~$ "$xyz" <( cat /dev/null ) >> + '' /dev/fd/63 >> ++ cat /dev/null >> bash: : command not found >> >> I don't know what else to tell you. Your customized environment is so >> ridiculously convoluted that NOBODY understands it, not even you. >> >> Either this is helpful, or not. I don't think you're going to get any >> better results from help-bash or bug-bash than this. >> >> In any case, I'm 99% sure this is not a bug in bash -- only in one of >> your files. >> >>
Re: some unknown bug, says : command not found
my fault i saw on the -x is an empty var indeed On Tue, Nov 2, 2021, 13:49 Alex fxmbsw7 Ratchev wrote: > i dont have "$var" <( sub ) i have $var <( sub ) > else it makes sense > > On Tue, Nov 2, 2021, 13:42 Greg Wooledge wrote: > >> On Tue, Nov 02, 2021 at 04:52:24AM +0100, Alex fxmbsw7 Ratchev wrote: >> > to answer around what was written, i dont have a cat alias >> > >> > but what mr andreas wrote seems much similiar to what i do, process >> sub.. >> > ill check the vars carefully but i dont get it fully >> >> unicorn:~$ bash >> unicorn:~$ $xyz <( true ) >> bash: /dev/fd/63: Permission denied >> unicorn:~$ "$xyz" <( true ) >> bash: : command not found >> >> > but, on your all tries to produce command not found, can u set -x the >> > tries, .. in mine it shows cat ... then command not found, like the >> > cat is gone somehow >> > means does yours produce a + cat ( or cmd ) and then just display >> command >> > not found >> >> unicorn:~$ bash >> unicorn:~$ set -x >> unicorn:~$ "$xyz" <( cat /dev/null ) >> + '' /dev/fd/63 >> ++ cat /dev/null >> bash: : command not found >> >> I don't know what else to tell you. Your customized environment is so >> ridiculously convoluted that NOBODY understands it, not even you. >> >> Either this is helpful, or not. I don't think you're going to get any >> better results from help-bash or bug-bash than this. >> >> In any case, I'm 99% sure this is not a bug in bash -- only in one of >> your files. >> >>
Re: some unknown bug, says : command not found
i dont have "$var" <( sub ) i have $var <( sub ) else it makes sense On Tue, Nov 2, 2021, 13:42 Greg Wooledge wrote: > On Tue, Nov 02, 2021 at 04:52:24AM +0100, Alex fxmbsw7 Ratchev wrote: > > to answer around what was written, i dont have a cat alias > > > > but what mr andreas wrote seems much similiar to what i do, process sub.. > > ill check the vars carefully but i dont get it fully > > unicorn:~$ bash > unicorn:~$ $xyz <( true ) > bash: /dev/fd/63: Permission denied > unicorn:~$ "$xyz" <( true ) > bash: : command not found > > > but, on your all tries to produce command not found, can u set -x the > > tries, .. in mine it shows cat ... then command not found, like the > > cat is gone somehow > > means does yours produce a + cat ( or cmd ) and then just display command > > not found > > unicorn:~$ bash > unicorn:~$ set -x > unicorn:~$ "$xyz" <( cat /dev/null ) > + '' /dev/fd/63 > ++ cat /dev/null > bash: : command not found > > I don't know what else to tell you. Your customized environment is so > ridiculously convoluted that NOBODY understands it, not even you. > > Either this is helpful, or not. I don't think you're going to get any > better results from help-bash or bug-bash than this. > > In any case, I'm 99% sure this is not a bug in bash -- only in one of > your files. > >
Re: bash support for XDG Base Directory spec (~/.config/bash/)
On Fri, May 7, 2021 at 11:48 AM Allison Karlitskaya < allison.karlitsk...@redhat.com> wrote: > hello, > > Please consider these two patches for inclusion in bash to support > storing shell initialisation files (profile, bashrc) in a subdirectory > of ~/.config/ as most programs do these days. > > I'm happy to make changes to address any feedback. > > Even if you'd prefer not to apply the second patch, applying the first > patch is a nice cleanup and would make it easier for distributions > such as Fedora to apply the second patch for themselves. > > Thank you very much for your consideration, > This issue is also discussed in Red Hat bug[1]. I will leave few notes about it here. >From the XDG specification[2]: - $XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. - $XDG_CONFIG_DIRS defines the preference-ordered set of base directories to search for configuration files in addition to the $XDG_CONFIG_HOME base directory. The directories in $XDG_CONFIG_DIRS should be seperated with a colon ':'. If $XDG_CONFIG_DIRS is either not set or empty, a value equal to /etc/xdg should be used. - The order of base directories denotes their importance; the first directory listed is the most important. When the same information is defined in multiple places the information defined relative to the more important base directory takes precedent. The base directory defined by $XDG_DATA_HOME is considered more important than any of the base directories defined by $XDG_DATA_DIRS. The base directory defined by $XDG_CONFIG_HOME is considered more important than any of the base directories defined by $XDG_CONFIG_DIRS. - Default configuration files should be installed to $sysconfdir/xdg/subdir/filename with $sysconfdir defaulting to /etc. Proposed patch doesn't fully implement this specification: - It doesn't cover the case when `$XDG_CONFIG_HOME` is defined. `$HOME/.config` should be only used if `$XDG_CONFIG_HOME` is not defined. (It's actually mentioned in the patch commit). - It doesn't cover the case when `$XDG_CONFIG_DIRS` environment variable is not defined. - It doesn't cover the case when `$XDG_CONFIG_DIRS` environment variable is defined. So even if we want to follow XDG specification, proposed patch has only partial implementation of it. Also, if it gets merged, it may require a change from package maintainers side to provide default configuration files under `$sysconfdir/xdg/subdir/filename`. On a side note, I believe bash startup configurations are already confusing for an average user and following XDG specification will just make it more complicated. > Allison > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1959284 [2] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Re: Assignment with colons *should* be tilde expanded in POSIX mode
On 11/1/21 6:37 PM, Anders Kaseorg wrote: As you know, POSIX requires tilde expansion following an an unquoted colon in an assignment [1]. A bug was reported [2] against bash 5.1-alpha that the tildes in $ echo foo=~:~ foo=~:~ should not be expanded in POSIX mode, because this is not an assignment. That was fixed in 5.1-beta. However, that fix also seems to have broken the actual assignment $ foo=~:~ $ echo "$foo" /home/anders:~ where both tildes should be expanded in POSIX mode, because this is an assignment. Thanks for the report. I'll take a look and fix whatever is wrong. Chet -- ``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/
Missing Backspace command in the readline
What is the Backspace code in the readline, i.e. .inputrc file (as the source come with explanation Ctrl-Backspace ( \b ) but not Backspace) ?
Re: Missing Backspace command in the readline
On 11/2/21 1:26 PM, Budi wrote: What is the Backspace code in the readline, i.e. .inputrc file (as the source come with explanation Ctrl-Backspace ( \b ) but not Backspace) ? Backspace is Control-H (^H, C-h). The default binding in emacs mode is backward-delete-char: $ bind -p | grep backward-delete-char "\C-h": backward-delete-char That binding usually comes in from the stty `erase' special character, but it's the default in the source. The usual result is that both DEL and BS are bound to backward-delete-char. This is not a bash bug. The question is more appropriate for help-bash. -- ``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 support for XDG Base Directory spec (~/.config/bash/)
Using XDG will have the complication that one normally sets environment variables like XDG_CONFIG_DIRS in ~/.bash_login. So I would add to the conversation, How much added value is there if XDG_CONFIG_DIRS is not used in practice? Dale
Re: Arbitrary command execution from test on a quoted string
elettrino via Bug reports for the GNU Bourne Again SHell writes: > The following shows an example of bash testing a quoted string and as > a result executing a command embedded in the string. > > Here I used the command "id" to stand as an example of a command. The > output of id on this machine was as follows: > > user@machine:~$ id > uid=1519(user) gid=1519(user) groups=1519(user),100(users) > user@machine:~$ > > So to demonstrate: > > user@machine:~$ USER_INPUT='x[$(id>&2)]' > user@machine:~$ test -v "$USER_INPUT" > uid=1519(user) gid=1519(user) groups=1519(user),100(users) > user@machine:~$ > > This means that if variable USER_INPUT was indeed input from a user, > the user could execute an arbitrary command. This is true, but two qualifications should be applied: 1. Executing "test -v" on user input doesn't make sense, as the variable-name space inside the shell isn't something the user should interact with. 2. It isn't a security problem, because the user could execute the command directly. I leave it to people more steeped in the aracana whether this action by "test -v" is an irregularity that should be changed. Dale
Re: Why should `break' and `continue' in functions not break loops running outside of the function?
OÄuz writes: >> It's a violation of scope. > > It's a violation of lexical scope, I'm asking why not implement > dynamic scope, what's wrong with it? Yes ... but the history of programming languages has been the history of learning that dynamic scoping is dangerous to program and lexical scoping is the Right Thing. >> Can you name *any* other language where functions can break out of their >> caller's loops? The only thing that comes to mind for me is C's "longjmp", >> which I've never used even once. (Not that I do any C programming these >> days, but back in the 1990s, I did.) The way to think about longjmp is that it's a goto that wrenches you out of nested contexts, somewhat like calling a completion in Scheme. But if you're using it sanely, it's clear what location the longjmp takes you to, whereas a dynamically-scoped break is not. Dale
