Re: [PATCH] glob: add shopt globmtimesort to sort globs by mtime
On Tue, Nov 15, 2022, 09:33 Alex fxmbsw7 Ratchev wrote: > i d be all for changeable glob s appearing > by chance integrate into loops expansion of array vars .. not just file globs .. > > On Tue, Nov 15, 2022, 02:40 Chet Ramey wrote: > >> On 10/3/22 2:56 PM, Evan Gates wrote: >> > --- >> > >> > There is currently no good way to sort files by mtime in the shell. >> > It's possible to do so with an ls that supports -t, but parsing ls is >> > problematic. >> >> Thanks for the patch. There are some good things here, usable stuff, but I >> think I'll look at a more general approach for the next version. >> >> 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/ >> >> >>
Re: [PATCH] glob: add shopt globmtimesort to sort globs by mtime
i d be all for changeable glob s appearing On Tue, Nov 15, 2022, 02:40 Chet Ramey wrote: > On 10/3/22 2:56 PM, Evan Gates wrote: > > --- > > > > There is currently no good way to sort files by mtime in the shell. > > It's possible to do so with an ls that supports -t, but parsing ls is > > problematic. > > Thanks for the patch. There are some good things here, usable stuff, but I > think I'll look at a more general approach for the next version. > > 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/ > > >
Re: string substitution broken since 5.2
On Fri, Nov 4, 2022, 19:42 Chet Ramey wrote:
> On 11/4/22 12:22 PM, Alex fxmbsw7 Ratchev wrote:
>
> > what on yours i ask , o i see now , 4.2 ..
> > i quote right in ${ // - to me , preserved quotes are • an invalid youth
> > bug to be replaced with better by bash.c changes
> > which it seemfully did
>
> The question is, as always, tradeoffs. Do you fix bugs or not? Do you make
> the behavior more consistent across operations, even if incompatibilities
> (as above) result? Do you tighten up behavior where previous versions were
> too permissive, even if people will have to change their code as a result,
> or not? Do you introduce new features, or not? Do you make things opt-in,
> or opt-out? The answers are not always the same.
>
i d ask me one other .. asking where 'the specific' s place is , to code it
there , where it belongs
Greg, for example, puts a lot of value in being able to use the same code
> from bash-4.2, which was released in 2010, through the current version.
> That's the tradeoff he's willing to make when answering these questions.
>
im a poor invalid-rent in swiss assed , tech++ privateer
to me only newest versions count ( preferabily containing feature addments )
to me as pro bash coder ( i sitted and learned and teachen further by
interactive computer chats ( mostly irc ) ) for years
.. to me , knowing all the bugs bash has over some time , makes me have big
anti reasons to use old bashes
i mean its one to support old
but , why does that old exist
redhat 5 6 7
they cant update ? or use extra , old softwre , to exploit flaws in sw
.. to support such .. no me man , not for me
i mean i got clauses here and there , in my coding freelance ing , one is
'pref. updated debian to run' - that is debian all public short tree s ,
not just useless 'stable' - and i d put it on as sometimes
i try to say , .. stuff is incomplete , and if fixes dont come , just as no
good as always it is
just as ppl support 4.2 i 'only newest'
greg did great examples btw
This was the entire rationale for the compatibility mode in the first
> place: if you want things as they were before, set the appropriate
> compatibility variable. The same is true of features controlled by shell
> options.
Backwards compatibility is important, and I put a lot of effort into it.
> But I nudge things forward when I think it's warranted. As you've seen,
> there's always spirited disagreement.
>
it s a vital work for you , ye
i can just say , changing quotes to be interpreted is imo vital too :p i
mean done correctly better now than before
when , you have smth , like sh or bash , or non computer stuff
it takes , its known-to-be , material-beeing
which will in time need changes to be done to it
hm hm , greets , x
--
> ``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: string substitution broken since 5.2
addition to my greycat-answer mail
.. i didnt use & there at all , my fault .. but with & its no else
root@localhost:~# a=i_am_foo b=_ c=${b}am$b d=$b\&$b e=${a//"$c"/"$d"} ;
printf ' --> %s\n' "$e" "${a//"$c"/"$d"}"
--> i_&_foo
--> i_&_foo
sorry
short imo , the ' " not parsing is outdated , and got fixed later
u may want bash v<1 compatibility ?
i just say its two horsrs , one about old and keep , the other about new
and updated
On Fri, Nov 4, 2022, 17:22 Alex fxmbsw7 Ratchev wrote:
>
>
> On Fri, Nov 4, 2022, 17:03 Greg Wooledge wrote:
>
>> On Fri, Nov 04, 2022 at 01:30:16PM +0100, Alex fxmbsw7 Ratchev wrote:
>> > > 1) Put something like "shopt -u patsub_replacement 2>/dev/null ||
>> true"
>> > >at the top of your script.
>> > >
>> >
>> > there d be many such senselessnesses
>> >
>> > >
>> > > 2) Assign the result of the expansion to a temporary variable, and
>> pass
>> > >the temp var to somecmd. Every. Single. Time.
>> > >
>> >
>> > ? i dont get that
>>
>> OK. Let me offer a quick example script. It works as expected in
>> bash-5.1:
>>
>> unicorn:~$ cat foo
>> #!/bin/bash
>> template='The best candy is clearly @CANDY@!'
>> candy='M'
>> printf '%s\n' "${template/@CANDY@/"$candy"}"
>>
>> unicorn:~$ ./foo
>> The best candy is clearly M!
>>
>> Now, let's run this script under bash-4.2:
>>
>> unicorn:~$ bash-4.2 ./foo
>> The best candy is clearly "M"!
>>
>> Uh oh! The quotes are wrong for bash-4.2. Bug #1 is filed for this
>> issue.
>> As the maintainer of the script, I test a few things between bash-4.2
>> and bash-5.1 and I come up with this workaround:
>>
>> unicorn:~$ cat foo
>> #!/bin/bash
>> template='The best candy is clearly @CANDY@!'
>> candy='M'
>> printf '%s\n' "${template/@CANDY@/$candy}"# unquote $candy to fix
>> bug #1
>>
>> unicorn:~$ bash-4.2 ./foo
>> The best candy is clearly M!
>> unicorn:~$ bash-5.1 ./foo
>> The best candy is clearly M!
>>
>> Now it works on older systems too. Everything's fine... until bash-5.2.
>>
>> unicorn:~$ bash-5.2 ./foo
>> The best candy is clearly M@CANDY@Ms!
>>
>> The workaround for bug #1 causes bug #2 on bash-5.2. To make the script
>> work on all three versions of bash, we need a different workaround:
>>
>> unicorn:~$ cat foo
>> #!/bin/bash
>> template='The best candy is clearly @CANDY@!'
>> candy='M'
>> message=${template/@CANDY@/"$candy"} # Work around bug #1 and
>> #2.
>> printf '%s\n' "$message"
>>
>> unicorn:~$ bash-4.2 ./foo
>> The best candy is clearly M!
>> unicorn:~$ bash-5.1 ./foo
>> The best candy is clearly M!
>> unicorn:~$ bash-5.2 ./foo
>> The best candy is clearly M!
>>
>> And there you have it. You're allowed to quote "$candy" in a variable
>> assignment, as long as the whole parameter expansion ${...} remains
>> unquoted, and it'll work properly in all 3 versions. I'm using "message"
>> as a temporary variable, whose sole purpose is to work around this issue.
>>
>
> mate , thank you for investing time in explainmennts
>
> what on yours i ask , o i see now , 4.2 ..
> i quote right in ${ // - to me , preserved quotes are • an invalid youth
> bug to be replaced with better by bash.c changes
> which it seemfully did
>
> is quotes preserveness the only bug here i see ?
>
> root@localhost:~# a=i_am_foo b=_ c=${b}am$b d=${b}be$b e=${a//"$c"/"$d"}
> ; printf ' --> %s\n' "$e" "${a//"$c"/"$d"}"
> --> i_be_foo
> --> i_be_foo
>
> for me , trying to support such wrongness , resulted ( along other same
> logics.. ) in a 'best is newest upstream version' rule
>
>>
Re: string substitution broken since 5.2
On Fri, Nov 4, 2022, 17:03 Greg Wooledge wrote:
> On Fri, Nov 04, 2022 at 01:30:16PM +0100, Alex fxmbsw7 Ratchev wrote:
> > > 1) Put something like "shopt -u patsub_replacement 2>/dev/null || true"
> > >at the top of your script.
> > >
> >
> > there d be many such senselessnesses
> >
> > >
> > > 2) Assign the result of the expansion to a temporary variable, and pass
> > >the temp var to somecmd. Every. Single. Time.
> > >
> >
> > ? i dont get that
>
> OK. Let me offer a quick example script. It works as expected in
> bash-5.1:
>
> unicorn:~$ cat foo
> #!/bin/bash
> template='The best candy is clearly @CANDY@!'
> candy='M'
> printf '%s\n' "${template/@CANDY@/"$candy"}"
>
> unicorn:~$ ./foo
> The best candy is clearly M!
>
> Now, let's run this script under bash-4.2:
>
> unicorn:~$ bash-4.2 ./foo
> The best candy is clearly "M"!
>
> Uh oh! The quotes are wrong for bash-4.2. Bug #1 is filed for this issue.
> As the maintainer of the script, I test a few things between bash-4.2
> and bash-5.1 and I come up with this workaround:
>
> unicorn:~$ cat foo
> #!/bin/bash
> template='The best candy is clearly @CANDY@!'
> candy='M'
> printf '%s\n' "${template/@CANDY@/$candy}"# unquote $candy to fix bug
> #1
>
> unicorn:~$ bash-4.2 ./foo
> The best candy is clearly M!
> unicorn:~$ bash-5.1 ./foo
> The best candy is clearly M!
>
> Now it works on older systems too. Everything's fine... until bash-5.2.
>
> unicorn:~$ bash-5.2 ./foo
> The best candy is clearly M@CANDY@Ms!
>
> The workaround for bug #1 causes bug #2 on bash-5.2. To make the script
> work on all three versions of bash, we need a different workaround:
>
> unicorn:~$ cat foo
> #!/bin/bash
> template='The best candy is clearly @CANDY@!'
> candy='M'
> message=${template/@CANDY@/"$candy"} # Work around bug #1 and #2.
> printf '%s\n' "$message"
>
> unicorn:~$ bash-4.2 ./foo
> The best candy is clearly M!
> unicorn:~$ bash-5.1 ./foo
> The best candy is clearly M!
> unicorn:~$ bash-5.2 ./foo
> The best candy is clearly M!
>
> And there you have it. You're allowed to quote "$candy" in a variable
> assignment, as long as the whole parameter expansion ${...} remains
> unquoted, and it'll work properly in all 3 versions. I'm using "message"
> as a temporary variable, whose sole purpose is to work around this issue.
>
mate , thank you for investing time in explainmennts
what on yours i ask , o i see now , 4.2 ..
i quote right in ${ // - to me , preserved quotes are • an invalid youth
bug to be replaced with better by bash.c changes
which it seemfully did
is quotes preserveness the only bug here i see ?
root@localhost:~# a=i_am_foo b=_ c=${b}am$b d=${b}be$b e=${a//"$c"/"$d"} ;
printf ' --> %s\n' "$e" "${a//"$c"/"$d"}"
--> i_be_foo
--> i_be_foo
for me , trying to support such wrongness , resulted ( along other same
logics.. ) in a 'best is newest upstream version' rule
>
Re: string substitution broken since 5.2
that u word comply to very outdated specs i did word bye On Fri, Nov 4, 2022, 15:26 Martin D Kealey wrote: > I now very much regret not commenting on this proposal during the > pre-release period, and I apologise for not having done so. > > On Fri, 4 Nov 2022, 05:50 Chet Ramey, wrote: > > > > > The option is enabled by default. If you want to restore the previous > > behavior, add `shopt -u patsub_replacement'. > > > > I am very disquieted by this pattern of creating breaking changes and then > saying "just add shopt blahblah to go back to the old behaviour". > > This might be justifiable to a fix for a security problem (e.g. array > subscripting), but *this* is just a nice-to-have feature. > > Suggesting that an existing script should be modified implies that scripts > must necessarily have "maintainers" whose job includes tracking changes to > the language provided by Bash, or that every piece of software installed on > a system comes from a single source who can test combinations for > compatibility. > > That is not the world that we live in. > > The average user out there has almost zero shell scripting experience, and > even less competence to diagnose faults in their system. They rely on a > package manager to install versions of basic utilities like Bash, and > diligently apply updates to keep on top of security. They also get other > software from sources who know nothing about them or their package manager. > > In this context the reasonable thing to do is to aim for maximal backwards > compatibility, and only enable breaking changes when a special option or > command is used. > > Can we please have an immediate point release turning this feature off by > default, and then let's take another look at how this can be done without > gratuitous breakage of existing code. > > -Martin > > PS: > I'm puzzled why a bare '&' was chosen in the first place; that seems to > provide the maximal likelihood of conflict with existing code. > > As an alternative that wouldn't need an enabling option, how about using > "$BASH_MATCH" or "$&"? (I suspect the latter would be easier to use as a > marker for a deferred expansion.) > > Rather than inserting a modal command or option, one possibility might be > to use the same mechanism as handles POSIX "sh", and extend it to look for > a trailing version number, and use that to enable new features. >
Re: string substitution broken since 5.2
On Fri, Nov 4, 2022, 12:33 Greg Wooledge wrote:
> On Fri, Nov 04, 2022 at 09:50:03AM +0100, Alex fxmbsw7 Ratchev wrote:
> > On Fri, Nov 4, 2022, 08:56 Léa Gris wrote:
> >
> > > Le 03/11/2022 à 19:50, Chet Ramey écrivait :
> > > > The option is enabled by default. If you want to restore the previous
> > > > behavior, add `shopt -u patsub_replacement'.
> > >
> > > Having it enabled by default is not good, because it introduces
> > > side-effects for existing scripts.
> > >
> >
> > there is , imo , no sense to comply to outdated specs to not add few more
> > of the infinite base features
> >
> > nevermind ..
>
> There is no "spec" for this. It's not a POSIX feature. It's a bashism.
>
its a 'basic' to me .. viral .. essential
i am talking mr chet bash , sticks much to , draft specs , some , and much
on backward compatibility
its hard to add features like this
i.. would care ppl get informed of bugs they use cause , very old versions
in use , and so ly u can even assure future updates
for them , its 'it works for me'
to me , its like non acceptable
To be clear, we're talking about:
>
> somecmd "${var//search/replace}"
>
> where "replace" might be a string contained in a variable.
>
> The reason this is an issue is because bash 5.2 has changed the default
> behavior of this expansion in a way that not only changes the behavior of
> existing scripts (possibly "breaking" them), but also makes it extremely
> difficult to write one script that works across all bash versions.
>
> In order to write a version-portable script that uses this feature,
> now you have to choose between these two workarounds:
>
i mean yea , for those who 'portable'
my, 'posix++' specs are even less portable
not of the logic
of the diswantings of the parties there
in future , specs drafts will grow and addments done..
in future.. we are far away from it .. :(
> 1) Put something like "shopt -u patsub_replacement 2>/dev/null || true"
>at the top of your script.
>
there d be many such senselessnesses
>
> 2) Assign the result of the expansion to a temporary variable, and pass
>the temp var to somecmd. Every. Single. Time.
>
? i dont get that
i just say its for me painful to have more keep-code-old ppl than -updated-
.. as an end user
sorry , greets , peace
>
Re: string substitution broken since 5.2
On Fri, Nov 4, 2022, 08:56 Léa Gris wrote: > Le 03/11/2022 à 19:50, Chet Ramey écrivait : > > The option is enabled by default. If you want to restore the previous > > behavior, add `shopt -u patsub_replacement'. > > Having it enabled by default is not good, because it introduces > side-effects for existing scripts. > there is , imo , no sense to comply to outdated specs to not add few more of the infinite base features nevermind .. > > Shell has historically perpetuated legacy features to preserve the > function of those no-longer maintained systems and associated scripts. > > Are there enough reasons to break this trend and stop preserving > backward-compatibility with older scripts; by enabling new features that > can affect the behaviour of previous code with side-effects? > > -- > Léa Gris > >
Re: local/typeset/declare -p - outputs invalid declare -- -
On Mon, Oct 31, 2022, 18:31 Greg Wooledge wrote: > On Mon, Oct 31, 2022 at 06:12:14PM +0100, Alex fxmbsw7 Ratchev wrote: > > hi , sorry.. whats the purpose of local - > > informational question > > a. Since there is no `declare -' equivalent of `local -', make sure to use >`local -' in the output of `local -p'. > > - > > s. The `local' builtin takes a new argument: `-', which will cause it to > save > the single-letter shell options and restore their previous values at > function return. > > From two different parts of CHANGES. > cool mate , perfect answer im sorry that i cant digg thru so much text but hey chat worked , =) hm it only saves the like -mBH or similiar ? hm dont get it much > >
Re: Multiline editing breaks if the previous output doesn't end in newline
where the cursor is ? some tput ansi code returns it .. but i guess u mean bigger compatibility problems does, readline, export its cursor assumptations ? like for dev'ing On Mon, Oct 31, 2022, 16:46 Chet Ramey wrote: > On 10/30/22 9:40 PM, Oğuz wrote: > > > Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only > if > > the cursor is not at column 0. > > There is no portable way to determine this. > > -- > ``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: local/typeset/declare -p - outputs invalid declare -- -
hi , sorry.. whats the purpose of local -
informational question
On Mon, Oct 31, 2022, 17:45 Emanuele Torre wrote:
> Since bash 5.2, local/typeset/declare -p without argument no longer
> outputs "declare -- -" when local - is used.
>
> But local/typeset/declare -p - still outputs "declare -- -" instead of
> "local -".
>
> bash-5.1$ a () { local -; local -p; declare -p -; typeset -p -;
> local -p - ;}
> bash-5.1$ a
> declare -- -
> declare -- -
> declare -- -
> declare -- -
>
> bash-5.2$ a () { local -; local -p; declare -p -; typeset -p -;
> local -p - ;}
> bash-5.2$ a
> local -
> declare -- -
> declare -- -
> declare -- -
>
>
Re: Multiline editing breaks if the previous output doesn't end in newline
On Sun, Oct 30, 2022, 23:01 Dennis Williamson wrote: > > > On Sun, Oct 30, 2022 at 4:41 PM Alex fxmbsw7 Ratchev > wrote: > >> >> >> i coded a files tree to bash code via gawk reading and printing bash code >> i did noeol no newline at end >> logically , cause , who wants var='from file\n' >> >> > >> > > Because command substitution strips trailing newlines? > no , sir i did simple files-in-dirs to bash-code i cant ( i did ) generate bash via bash , but it was too slow the current uses gawk to generate project bash code in one run with find \0 as input for , to file , or eval , source .. my point with the newlines i came across when processing the files 1:1 , i think it began with mapfile usage but gawk does as well there is to me , not knowing end newline(s) count , only a ( too ) fatal disability it also makes data processing , a pain to me the ansi or whatever newline ending rule is , as i try to say , nothing profitable what i mean in my example is when normally writing a file in vim , it ends with the big time ignored newline say one has vars/foo with content 'bar' my code would produce , along var stacking , foo='bar ' to me , as data cruncher , one to one data preservance is must so i changed vim settings to skip this ending newline there is also another case if use for exactness that is data stacking in sequencial files sometimes \n sometimes not hopes for good , /peace $ echo -e 'foo\n\n\n' > foo > > > > $ s=$(echo -e 'foo\n\n\n') > $ declare -p s > declare -- s="foo" > > No gyrations needed. > -- > Visit serverfault.com to get your system administration questions > answered. >
Re: Multiline editing breaks if the previous output doesn't end in newline
On Sun, Oct 30, 2022, 21:21 Albert Vaca Cintora wrote: > On Sun, Oct 30, 2022 at 7:54 AM Martin D Kealey > wrote: > > > > This sounds like a bug in whatever is producing the output. POSIX text > files have a newline terminating every line; that description includes > streams going through pipes and tty devices if they purport to be text. > > > > There are many reasons why one could end up with text in a terminal > that doesn't end in a newline. A couple of them are: > - An app is killed in the middle of writing its output (eg: because of > a sigterm/sigkill). > - A file that isn't a POSIX text file is printed to the terminal. > > So I think this should still be handled by bash. > i coded a files tree to bash code via gawk reading and printing bash code i did noeol no newline at end logically , cause , who wants var='from file\n' >
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
On Sun, Oct 30, 2022, 11:33 Oğuz wrote:
> 30 Ekim 2022 Pazar tarihinde Martin D Kealey
> yazdı:
> >
> > So the options would seem to be:
> > (a) prohibit inversions (you get to pick EITHER extglob or rexglob, not
> > both);
> > (b) bypass convert-to-regex when inversions are present;
> > (c) use PCRE or Vim RE, which already support negations (though not in
> the
> > same form); note that these do not have linear ("regular") time
> performance
> > in any but the trivial cases;
> > (d) compute the "inverse" regex for a given negation (this may require
> Vim
> > RE, see below);
> > (e) post-process the compiled regex (this would be highly dependent on
> the
> > specific RE implementation);
> > (f) pick an existing regex engine, and add the necessary logic to handle
> > negations and conjunctions (see below);
> >
>
> Or
> (g) make the existing extglob code faster and avoid introducing more
> complexity into the shell.
>
> Which, in my opinion, is the easiest and most realistic option.
>
last three times i bugged about glob ( like reuse groupings ) it sounded
'do-it-yourself' back only
i would , have done , if i could ( .c )
--
> Oğuz
>
Re: feature request: new builtin `defer`, scope delayed eval
On Sat, Oct 8, 2022, 12:03 Oğuz wrote: > 8 Ekim 2022 Cumartesi tarihinde Cynthia Coan yazdı: > > > > [...] I think > > use cases outside of cleanup are relatively sparse, [...] > > > There. There already are several ways to do cleanup on exit/return using > existing features, why add one more? > > > > [...] With your syntax you still have to be aware of what's > > in that trap [...] > > > > Not really. If, for some reason, I didn't know what's in that trap and were > super paranoiac about it, I could do > > oldaction=$(trap -P EXIT) > trap 'eval "$oldaction"; bar' EXIT > > I've never been in such a situation though. > there is, run code addment / management , for trap code > > Don't get me wrong, I just like it when new features align with the old > ones and work together nicely. > > > -- > Oğuz >
Re: Light weight support for JSON
On Sun, Aug 28, 2022, 15:46 Yair Lenga wrote:
> Sorry for not being clear. I'm looking for feedback. The solution that I
> have is using python to read the JSON, and generate the commands to build
> the associative array. Will have to rewrite in "C"/submit if there is
> positive feedback from others readers. Yair.
>
ah, cool
i just have a suggestion, .. to store the keys in a separate array, space
safe
On Sun, Aug 28, 2022 at 9:42 AM Alex fxmbsw7 Ratchev
> wrote:
>
>>
>>
>> On Sun, Aug 28, 2022, 15:25 Yair Lenga wrote:
>>
>>> Hi,
>>>
>>> Over the last few years, JSON data becomes a integral part of processing.
>>> In many cases, I find myself having to automate tasks that require
>>> inspection of JSON response, and in few cases, construction of JSON. So
>>> far, I've taken one of two approaches:
>>> * For simple parsing, using 'jq' to extract elements of the JSON
>>> * For more complex tasks, switching to python or Javascript.
>>>
>>> Wanted to get feedback about the following "extensions" to bash that will
>>> make it easier to work with simple JSON object. To emphasize, the goal is
>>> NOT to "compete" with Python/Javascript (and other full scale language) -
>>> just to make it easier to build bash scripts that cover the very common
>>> use
>>> case of submitting REST requests with curl (checking results, etc), and
>>> to
>>> perform simple processing of JSON files.
>>>
>>> Proposal:
>>> * Minimal - Lightweight "json parser" that will convert JSON files to
>>> bash
>>> associative array (see below)
>>> * Convert bash associative array to JSON
>>>
>>> To the extent possible, prefer to borrow from jsonpath syntax.
>>>
>>> Parsing JSON into an associative array.
>>>
>>> Consider the following, showing all possible JSON values (boolean,
>>> number,
>>> string, object and array).
>>> {
>>> "b": false,
>>> "n": 10.2,
>>> "s: "foobar",
>>> x: null,
>>> "o" : { "n": 10.2, "s: "xyz" },
>>> "a": [
>>> { "n": 10.2, "s: "abc", x: false },
>>> { "n": 10.2, "s": "def" x: true},
>>> ],
>>> }
>>>
>>> This should be converted into the following array:
>>>
>>> -
>>>
>>> # Top level
>>> [_length] = 6# Number of keys in object/array
>>> [_keys] = b n s x o a# Direct keys
>>> [b] = false
>>> [n] = 10.2
>>> [s] = foobar
>>> [x] = null
>>>
>>> # This is object 'o'
>>> [o._length] = 2
>>> [o._keys] = n s
>>> [o.n] = 10.2
>>> [o.s] = xyz
>>>
>>> # Array 'a'
>>> [a._count] = 2 # Number of elements in array
>>>
>>> # Element a[0] (object)
>>> [a.0._length] = 3
>>> [a.0._keys] = n s x
>>> [a.0.n] = 10.2
>>> [a.0.s] = abc
>>> [a.0_x] = false
>>>
>>> -
>>>
>>> I hope that example above is sufficient. There are few other items that
>>> are
>>> worth exploring - e.g., how to store the type (specifically, separate the
>>> quoted strings vs value so that "5.2" is different than 5.2, and "null"
>>> is
>>> different from null.
>>>
>>
>> did you forget to send the script along ? or am i completly loss
>>
>> a small thing i saw, a flat _keys doesnt do the job..
>>
>> I will leave the second part to a different post, once I have some
>>> feedback. I have some prototype that i've written in python - POC - that
>>> make it possible to write things like
>>>
>>> declare -a foo
>>> curl http://www.api.com/weather/US/10013 | readjson foo
>>>
>>> printf "temperature(F) : %.1f Wind(MPH)=%d" ${foo[temp_f]}, ${foo[wind]}
>>>
>>> Yair
>>>
>>
Re: Light weight support for JSON
On Sun, Aug 28, 2022, 15:25 Yair Lenga wrote:
> Hi,
>
> Over the last few years, JSON data becomes a integral part of processing.
> In many cases, I find myself having to automate tasks that require
> inspection of JSON response, and in few cases, construction of JSON. So
> far, I've taken one of two approaches:
> * For simple parsing, using 'jq' to extract elements of the JSON
> * For more complex tasks, switching to python or Javascript.
>
> Wanted to get feedback about the following "extensions" to bash that will
> make it easier to work with simple JSON object. To emphasize, the goal is
> NOT to "compete" with Python/Javascript (and other full scale language) -
> just to make it easier to build bash scripts that cover the very common use
> case of submitting REST requests with curl (checking results, etc), and to
> perform simple processing of JSON files.
>
> Proposal:
> * Minimal - Lightweight "json parser" that will convert JSON files to bash
> associative array (see below)
> * Convert bash associative array to JSON
>
> To the extent possible, prefer to borrow from jsonpath syntax.
>
> Parsing JSON into an associative array.
>
> Consider the following, showing all possible JSON values (boolean, number,
> string, object and array).
> {
> "b": false,
> "n": 10.2,
> "s: "foobar",
> x: null,
> "o" : { "n": 10.2, "s: "xyz" },
> "a": [
> { "n": 10.2, "s: "abc", x: false },
> { "n": 10.2, "s": "def" x: true},
> ],
> }
>
> This should be converted into the following array:
>
> -
>
> # Top level
> [_length] = 6# Number of keys in object/array
> [_keys] = b n s x o a# Direct keys
> [b] = false
> [n] = 10.2
> [s] = foobar
> [x] = null
>
> # This is object 'o'
> [o._length] = 2
> [o._keys] = n s
> [o.n] = 10.2
> [o.s] = xyz
>
> # Array 'a'
> [a._count] = 2 # Number of elements in array
>
> # Element a[0] (object)
> [a.0._length] = 3
> [a.0._keys] = n s x
> [a.0.n] = 10.2
> [a.0.s] = abc
> [a.0_x] = false
>
> -
>
> I hope that example above is sufficient. There are few other items that are
> worth exploring - e.g., how to store the type (specifically, separate the
> quoted strings vs value so that "5.2" is different than 5.2, and "null" is
> different from null.
>
did you forget to send the script along ? or am i completly loss
a small thing i saw, a flat _keys doesnt do the job..
I will leave the second part to a different post, once I have some
> feedback. I have some prototype that i've written in python - POC - that
> make it possible to write things like
>
> declare -a foo
> curl http://www.api.com/weather/US/10013 | readjson foo
>
> printf "temperature(F) : %.1f Wind(MPH)=%d" ${foo[temp_f]}, ${foo[wind]}
>
> Yair
>
Re: ${!#} doesnt get into history in interactive
On Thu, Aug 25, 2022, 16:27 Chet Ramey wrote:
> On 8/25/22 2:04 AM, Alex fxmbsw7 Ratchev wrote:
>
> >
> > is this a bug, i see it as wrong feature
> >
> > the set -- 1 2 3 line was also gone - why ?
> >
> > it printed for !# 3 it didnt histexpand-act
>
> I can't reproduce this.
>
:/ , thanks much tho for looking into it
i put it to the x-files
greets :))
$ echo $BASH_VERSION
> 5.2.0(1)-rc3
> $ history -c
> $ echo 1
> 1
> $ echo 2
> 2
> $ echo 3
> 3
> $ echo ${!#}
> ./bash
> $ history
> 1 echo 1
> 2 echo 2
> 3 echo 3
> 4 echo ${!#}
> 5 history
>
>
> --
> ``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: ${!#} doesnt get into history in interactive
On Wed, Aug 24, 2022, 21:15 Dennis Williamson
wrote:
>
>
> On Wed, Aug 24, 2022, 9:07 AM Alex fxmbsw7 Ratchev
> wrote:
>
>> debian 5.2.0(1)-beta bash
>>
>> i did code lightly in interactive
>> then i did
>>
>> set -- 1 2 3
>> echo ${!#}
>>
>> then arrow up
>> .. both cmds were skipped , and on the term was rather the old code ,
>> which
>> i previously wrote
>>
>> then i did
>>
>> echo ${!#}
>>
>> arrow up
>> .. the old cmd again
>>
>> attached is a pic from camera on that screen
>>
>> imo i dont have much in bashrc
>> pic of that also
>>
>
> set +o histexpand
>
is this a bug, i see it as wrong feature
the set -- 1 2 3 line was also gone - why ?
it printed for !# 3 it didnt histexpand-act
..
>
Re: add custom environment variable in bash source code
On Thu, Aug 18, 2022, 04:10 Dale R. Worley wrote: > Sam writes: > > You probably want to edit /etc/ld.so.conf or /etc/ld.so.conf.d/* instead. > > The overall concept is that you almost certainly don't want to modify > the bash source code (and thus executable) to do this. > > In general, if you want to have a particular environment variable set > "all the time", you insert "export X=..." in one of your startup files. > If you want it visible to everybody, you insert that in one of the > system startup files. Depending on exactly what processes you want > affected and how your OS handles these things determines which file to > modify. > > However, the original question is > > > I want to automatically add LD_PRELOAD before starting bash to make > > this dynamic library work > > I see looking at the ld.so manual page: > >/etc/ld.so.preload > File containing a whitespace-separated list of ELF > shared > libraries to be loaded before the program. > > So if what you want is for all processes to preload a particular > library, add its name to this file. Or rather, check how your > particular OS provides this facility. > > Dale > i think they mean android nonroot default fyi asker termux does just change #! to its android path >
Re: Re: Re: add custom environment variable in bash source code
no .. i say im not good at .c yet On Thu, Aug 18, 2022, 01:36 wrote: > Sorry, I don't understand what you want me, you can send a .diff file > tells me how to do? > > 在 2022-08-18 07:26:45，"Alex fxmbsw7 Ratchev" 写道： > > > > > On Thu, Aug 18, 2022, 01:19 wrote: > > Because I'm using Android, Android doesn't support #!/bin/sh and > #!/bin/bash, there is a dynamic library that fixes it, so I want to > automatically add LD_PRELOAD before starting bash to make this dynamic > library work , I want to modify the source code of bash to make it > effective, not the bash.bashrc and profile files in the etc directory,what > should I do, can you send a video attachment to teach me? > > > > erm, im not yet a .c number > > > > > > > > 在 2022-08-18 00:19:24，"Alex fxmbsw7 Ratchev" 写道： > > maybe just 'eval "declare -gx var=value"' in bash.c code > > > what i meant with this is hint at something a .c coder can do > can u code .c ? > > > .. search in the codes the .c named ld preload and ld paths identifiers ( > how they are named ) then search for those, to see where they act > and add a static prefix yours at a safe position and safe code > > > > > On Wed, Aug 17, 2022, 17:53 Chet Ramey wrote: > > On 8/16/22 10:09 PM, b1431736...@163.com wrote: > > > Bash Version: 5.1 > > Patch Level: 16 > > Release Status: release > > > > Description: > > excuse me, how can I join the custom environment variable into > the source code of Bash, and see this variable when execute env > > What is it you want to do? You rarely need to add code to bash to do > something like that. > > -- > ``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: Re: add custom environment variable in bash source code
( or use the eval function ( dunno its name and usage ) and eval your two var assignments ) On Thu, Aug 18, 2022, 01:26 Alex fxmbsw7 Ratchev wrote: > > > On Thu, Aug 18, 2022, 01:19 wrote: > >> >> Because I'm using Android, Android doesn't support #!/bin/sh and >> #!/bin/bash, there is a dynamic library that fixes it, so I want to >> automatically add LD_PRELOAD before starting bash to make this dynamic >> library work , I want to modify the source code of bash to make it >> effective, not the bash.bashrc and profile files in the etc directory,what >> should I do, can you send a video attachment to teach me? >> > > erm, im not yet a .c number > > > > >> 在 2022-08-18 00:19:24，"Alex fxmbsw7 Ratchev" 写道： >> >> maybe just 'eval "declare -gx var=value"' in bash.c code >> >> > what i meant with this is hint at something a .c coder can do > can u code .c ? > > .. search in the codes the .c named ld preload and ld paths identifiers ( > how they are named ) then search for those, to see where they act > and add a static prefix yours at a safe position and safe code > > >> On Wed, Aug 17, 2022, 17:53 Chet Ramey wrote: >> >>> On 8/16/22 10:09 PM, b1431736...@163.com wrote: >>> >>> > Bash Version: 5.1 >>> > Patch Level: 16 >>> > Release Status: release >>> > >>> > Description: >>> > excuse me, how can I join the custom environment variable >>> into the source code of Bash, and see this variable when execute env >>> >>> What is it you want to do? You rarely need to add code to bash to do >>> something like that. >>> >>> -- >>> ``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: Re: add custom environment variable in bash source code
On Thu, Aug 18, 2022, 01:19 wrote: > > Because I'm using Android, Android doesn't support #!/bin/sh and #!/bin/bash, > there is a dynamic library that fixes it, so I want to automatically add > LD_PRELOAD before starting bash to make this dynamic library work , I want to > modify the source code of bash to make it effective, not the bash.bashrc and > profile files in the etc directory,what should I do, can you send a video > attachment to teach me? > erm, im not yet a .c number > 在 2022-08-18 00:19:24，"Alex fxmbsw7 Ratchev" 写道： > > maybe just 'eval "declare -gx var=value"' in bash.c code > > what i meant with this is hint at something a .c coder can do can u code .c ? .. search in the codes the .c named ld preload and ld paths identifiers ( how they are named ) then search for those, to see where they act and add a static prefix yours at a safe position and safe code > On Wed, Aug 17, 2022, 17:53 Chet Ramey wrote: > >> On 8/16/22 10:09 PM, b1431736...@163.com wrote: >> >> > Bash Version: 5.1 >> > Patch Level: 16 >> > Release Status: release >> > >> > Description: >> > excuse me, how can I join the custom environment variable into >> the source code of Bash, and see this variable when execute env >> >> What is it you want to do? You rarely need to add code to bash to do >> something like that. >> >> -- >> ``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: add custom environment variable in bash source code
maybe just 'eval "declare -gx var=value"' in bash.c code On Wed, Aug 17, 2022, 17:53 Chet Ramey wrote: > On 8/16/22 10:09 PM, b1431736...@163.com wrote: > > > Bash Version: 5.1 > > Patch Level: 16 > > Release Status: release > > > > Description: > > excuse me, how can I join the custom environment variable into > the source code of Bash, and see this variable when execute env > > What is it you want to do? You rarely need to add code to bash to do > something like that. > > -- > ``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: Performances comparission between 5.1 and 5.2.
On Mon, Aug 15, 2022, 21:42 Eduardo Bustamante wrote: > On Mon, Aug 15, 2022 at 10:09 AM Greg Wooledge wrote: > > > On Mon, Aug 15, 2022 at 07:05:49PM +0200, felix wrote: > > > Description: > > > Trying some script under 5.2 beta, rc1 and rc2, I was surprised > by > > execution time. > > > > Pre-release versions of bash are built with extra debugging stuff, and > > will not perform like full-release versions. > > > > Chet explains this in > https://lists.gnu.org/archive/html/bug-bash/2014-01/msg00126.html thank you sir by chance, how to disable all suches .. ? > >
Re: Performances comparission between 5.1 and 5.2.
catastrophal numbers, ..
On Mon, Aug 15, 2022, 19:06 felix wrote:
> Configuration Information:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2
> uname output: Linux medium 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1
> (2022-03-07) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.2
> Patch Level: 0
> Release Status: rc2
>
> Description:
> Trying some script under 5.2 beta, rc1 and rc2, I was surprised by
> execution time.
> In order to compare, I've tried to establish execution time of
> elementar operations, like:
>
> - {0..999}.`: {0..999}`
> - 3x{0..9} `: {0..9}{0..9}{0..9}`
> - readUt `read -r ut idl - RE `[[ $cnt =~ ^[0-9]*\..*$ ]]`
> - InLneStr `: <<<"Hello world!"`
> - IncInt `int+=1`
> - AccessRt `: "$EPOCHREALTIME"`
> - PrintF `printf -v int '%s+%s' $int 1`
>
> Here is results of my comparission between different version of
> bash:
> (1st column show number of empty loop in 0.2 seconds as reference)
> $ for((i=0;i<${#bashs[@]};i++)){ ${bashs[i]} timedTest.sh
> ${args[i]:--q};}
> l/.2s{0..999}3x{0..9} readUt RE
> InLneStr IncIntAccessRt PrintF VersionBuildDir
> 66222 330.31 338.28 13.17 19.02
> 63.160.082.691.18 5.0.17(1)-release
> /tmp/bash/bash-5.0/bash
> 73720 366.97 379.70 13.20 17.80
> 10.090.102.461.19 5.1.4(1)-release /bin/bash
> 60585 409.92 419.53 13.62 19.87
> 10.870.093.001.38 5.1.4(1)-release
> /tmp/bash/bash-5.1.4/bash
> 62416 417.85 423.23 14.63 20.84
> 11.340.363.051.43 5.1.4(1)-release
> /tmp/bash/bash-5.1.4/bash_dynlib
> 62538 416.97 439.28 13.65 20.69
> 12.510.293.051.57 5.1.4(1)-release
> /tmp/bash/debian/bash-5.1/bash
> 60664 419.54 425.89 14.25 21.05
> 11.010.573.121.38 5.1.16(1)-release
> /tmp/bash/bash-5.1.16/bash
> 4080839995.1039995.10 18.49 35.46
> 15.650.345.812.40 5.2.0(1)-beta
> /tmp/bash/bash-5.2-beta/bash
> 4013433328.3539995.02 18.88 31.18
> 14.730.296.192.20 5.2.0(1)-rc1
> /tmp/bash/bash-5.2-rc1/bash
> 4035039995.0439995.04 19.10 32.20
> 14.660.596.152.26 5.2.0(1)-rc2
> /tmp/bash/bash-5.2-rc2/bash
>
> Where if everything seem slower, accessing $EPOCHREALTIME like
> `prinf -v INTEGER '%s+%s' $INTEGER 1` or
> using Regular Expression use approx 2x more time, but a sequence
> of 1000 using brace expansion require 100x more time!!
>
> Another test (first script I wrote) is something slower, but
> render approx same results:
> $ for((i=0;i<${#bashs[@]};i++)){ ${bashs[i]} looptest.sh
> ${args[i]:--q};}
> l/.02s{0..999}3x{0..9} readUt RE
> InLneStr IncIntAccessRt PrintF VersionBuildDir
>1468 340.47 348.36 16.71 22.54
> 51.441.715.103.51 5.0.17(1)-release bash-5.0/bash
>1714 366.64 380.21 15.11 20.11
> 12.231.333.992.35 5.1.4(1)-release /bin/bash
>1074 414.53 423.91 15.91 22.94
> 12.781.724.772.54 5.1.4(1)-release
> bash-5.1.4/bash
>1444 413.59 418.95 16.80 22.83
> 13.211.704.712.51 5.1.4(1)-release
> bash-5.1.4/bash_dynlib
>1360 421.20 432.83 16.33 22.79
> 12.981.824.872.59 5.1.4(1)-release
> debian/bash-5.1/bash
>1134 420.00 428.62 16.76 22.74
> 13.121.784.922.60 5.1.16(1)-release
> bash-5.1.16/bash
> 68740158.2140676.12 23.73 38.81
> 18.983.969.873.94 5.2.0(1)-beta
> bash-5.2-beta/bash
> 60739559.7140192.35 23.38 37.68
> 19.083.959.983.99 5.2.0(1)-rc1
> bash-5.2-rc1/bash
> 74040531.7640965.16 24.38 37.99
> 19.133.94 10.053.95 5.2.0(1)-rc2
> bash-5.2-rc2/bash
>
> Repeat-By:
> https://f-hauri.ch/vrac/timedTest.sh.txt
> https://f-hauri.ch/vrac/looptest.sh.txt
>
> --
> Félix Hauri -- http://www.f-hauri.ch
>
>
Re: Revisiting Error handling (errexit)
On Fri, Jul 8, 2022, 12:44 Koichi Murase wrote: > 2022年7月8日(金) 19:29 Alex fxmbsw7 Ratchev : > > > > ls -l /production/path | mail -s "all-good" not...@company.com > || > > > > true# Not critical > > > > > > > small side note there, a || true is big slow imho > > What does it mean? If you are talking about the execution time, "|| > true" is much faster than spawning external processes like "ls" and > "mail". I've measured it in my system, but the overhead by "|| true" > is about 270ns (assuming the error basically does not happen if the > environment is properly set up) while the overhead by a pipe "ls -l | > cat -v" (where I replaced "mail ..." with "cat -v") is about > 6630200ns. The main command is 2.5x10^6 times slower. In real cases, I > would expect that "mail" would take much more time than "mail". Even > if the main command does not "fork" or "exec" new processes, I believe > 270ns is always negligible. > > -- > Koichi > hi mate i always mean high speed serial as mass as possible aka, i would never use this code ever, excepts its not my rules also not meaning the 'never hit' at all case dont mind me mate, im outdated i dont computer atm since long greets >
Re: Revisiting Error handling (errexit)
On Fri, Jul 8, 2022, 12:23 Oğuz wrote:
> 8 Temmuz 2022 Cuma tarihinde Yair Lenga yazdı:
> >
> > Practical Example - real life. A job has to copy 3 critical data files.
> It
> > then sends notification via email (non-critical).
> >
> > #! /bin/bash
> > set -o errfail
> > function copy-files {
> > # ALL files are critical, script will not cont
> > cp /new/file1 /production/path/
> > cp /new/file2 /production/path/
> > # Use the files for something - e.g., count the lines.
> > important-job /production/path/file1 /production/path/file2
> >
> > ls -l /production/path | mail -s "all-good" not...@company.com ||
> > true# Not critical
>
small side note there, a || true is big slow imho
> }
> >
> > if copy-files ; then
> > more-critical-jobs
> > echo "ALL GOOD"
> > else
> > mail -s "PROBLEM" nor...@company.com < /dev/null
> > fi
> >
> > What is the difference ? consider the case where /new/file1 does not
> > exists, which is critical error.
> > * Without errfail, an error message will be sent to script stderr, but
> the
> > script will continue to copy the 2nd file, and to perform the
> > important-job, even though the data is not ready.
>
>
> How is this any better than doing `cp ... && cp ... && important-job ...'?
>
>
> --
> Oğuz
>
Re: [Unknown error when running a simple bash script]
On Mon, Jul 4, 2022, 18:07 wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto > -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security > -Wall > uname output: Linux asus-laptop.example.com 5.15.0-27-generic #28-Ubuntu > SMP Thu Apr 14 04:55:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.1 > Patch Level: 16 > Release Status: release > > Description: > [I am trying to run an if loop in my script and the if loop has a > conditional statement, if [[ $input == "y" ]]; then echo "Some text". > > When I am running the script, it says "[[: not found." > > Please let me know the solution of this problem. > you sure its bash u run ? echo $SHELL and see >
Re: executes statement after "exit"
dude u didnt get, in your example : is already the cmd
therenis no 'exit cmd' in your code
only exit as arg to :
On Fri, Apr 15, 2022, 20:36 Frank Heckenbach
wrote:
> > > #!/bin/bash
> > > : $((08 + 0)); exit
> > > echo "Should not get here."
> >
> > It never executes `exit'.
> >
> > The explanation in
> > https://lists.gnu.org/archive/html/bug-bash/2022-04/msg00010.html
> applies here.
> >
> > The arithmetic syntax error (invalid octal constant) results in a word
> > expansion error (the $((...)) ), which causes the shell to abort
> execution
> > of the current command (the command list)
>
> Current command means command list? Is this actually documented
> somewhere?
>
> E.g., in "3.5.6 Process Substitution" the manual says:
> "The process list is run asynchronously, and its input or output
> appears as a filename. This filename is passed as an argument to the
> current command as the result of the expansion."
>
> So if "current command" is the command list, in
>
> sleep 3; : <(echo foo >&2)
>
> shouldn't it start the "echo" before the "sleep" (in order to pass
> its stdout as a filename to the command list)? It doesn't seem to do
> so. So here, "current command" apparently means a simple command
> (or in other cases, a compound command), but not a command list.
>
> > and jump back to the top level
> > to continue execution with the next command (echo).
>
> Let't see. This is a command list, so according to your explanation,
> due to the expansion error, neither the "exit" nor the "echo" is
> run:
>
> : $((08 + 0)); exit; echo "Should not get here."
>
> Alright. Now, in "3.2.4 Lists of Commands" it says:
>
> "A sequence of one or more newlines may appear in a list instead of a
> semicolon to delimit commands."
>
> So let's do this for the latter semicolon, resulting in:
>
> : $((08 + 0)); exit
> echo "Should not get here."
>
> According to the above, this should still be one command list, so
> the "echo" shouldn't run either, but it does.
>
> > POSIX requires the shell to exit on a word expansion error, which bash
> does
> > in posix mode.
>
> This actually seems the saner behaviour rather than continuing at some
> arbitrary point -- which I guess is well-defined in some sense, but
> really unobvious to the programmer and very fragile since it changes
> when a block is moved to a function, put inside an "if"-statement or
> just has the formatting (";" vs. newline) changed ...
>
>
Re: Bash regexp parsing would benefit from safe recursion limit
On Wed, Mar 30, 2022 at 7:47 PM Martin Schulte wrote: > Hello Willi! > > > Fix: > > Count the stack frames during recursive parsing and emit error before > stack > > resources are entirely consumed. > > What exactly should happen and what is the benefit of this solution? > i guess it wont segfault anymore .. > > BTW: I tried > > trap 'echo "Ohohoh..."; exit 1;' SIGSEGV > > but the signal wasn't caught (which didn't really surprise me). > > Best regards > > Martin > >
Re: defuncted printf process when using wpa_supplicant
On Wed, Mar 30, 2022, 16:58 Greg Wooledge wrote: > On Wed, Mar 30, 2022 at 04:52:16PM +0200, Alex fxmbsw7 Ratchev wrote: > > cool mate i halfway understand but great peaceful explaintion :) > > The most important thing here is that zombies are mostly harmless. > They aren't using any memory or CPU. The only thing they're using is > a PID, and the kernel resources associated with that (a few dozen bytes > to store the process's "name" and so on). > > Unless there are thousands of them, you can just ignore them. > k cool >
Re: defuncted printf process when using wpa_supplicant
On Wed, Mar 30, 2022, 16:15 Chet Ramey wrote:
> On 3/30/22 1:40 AM, Alex fxmbsw7 Ratchev wrote:
> > i do
> >
> > wpa_supplicant -i"$if" -c<( printf %s\\n \
> > 'network={' "ssid=\"$ssid\"" "psk=\"$pass\"" '}'
> > ) &
> > { sleep 3 ; dhclient "$if" ; } &
> >
> > which is simply wpa_supplicant -iiface -c<( conf file printing )
> >
> > it since years resuts in such : i think before it said printf defuncted
>
> Since printf is a shell builtin, there's no way for ps to reliably
> determine the name of the command in the process substitution.
>
> > root 1530 0.0 0.0 0 0 ?Z07:19 0:00 \_
> > [3.wpa]
>
> Since the command is asynchronous, the shell forks and does word expansion
> in the subshell, at which point it creates the pipes for the process
> substitution. It then suppresses any additional forks and simply execs the
> sleep process. The shell started to run the process substitution sits there
> peacefully, not consuming any resources, until wpa_supplicant exits and
> everything gets reaped by init/systemd/whatever.
>
cool mate i halfway understand but great peaceful explaintion :)
--
> ``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: defuncted printf process when using wpa_supplicant
On Wed, Mar 30, 2022, 13:53 Andreas Schwab wrote: > On Mär 30 2022, Greg Wooledge wrote: > > > If it turns out that wpa_supplicant is the parent, then that's the > > responsible party, and that's where you should send your bug reports. > > Processes don't know about process substitutions set up by the shell, > thus they cannot be resposible for them. > > $ sleep 1000 < <(cat /dev/null) & > [1] 10418 > > 10418 pts/13 S 0:00 | \_ sleep 1000 > 10419 pts/13 Z 0:00 | | \_ [cat] > i see .. -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." > >
Re: defuncted printf process when using wpa_supplicant
On Wed, Mar 30, 2022, 13:30 Greg Wooledge wrote:
> On Wed, Mar 30, 2022 at 07:40:22AM +0200, Alex fxmbsw7 Ratchev wrote:
> > i do
> >
> > wpa_supplicant -i"$if" -c<( printf %s\\n \
> > 'network={' "ssid=\"$ssid\"" "psk=\"$pass\"" '}'
> > ) &
> > { sleep 3 ; dhclient "$if" ; } &
> >
> > which is simply wpa_supplicant -iiface -c<( conf file printing )
> >
> > it since years resuts in such : i think before it said printf defuncted
> >
> >
> > root 1528 0.0 0.0 12388 8656 ?S07:19 0:01
> > wpa_supplicant -iwlo1 -c/dev/fd/63
> > root 1530 0.0 0.0 0 0 ?Z07:19 0:00 \_
> > [3.wpa]
>
> Whatever ps command you're using here isn't showing the parent process
> ID. You'll need the parent PID to know which program isn't cleaning
> up its defunct children (zombies).
>
> The "-f" (SysV-ish) option to Linux's ps command will show it:
>
i seem not to have it, f was for tree shitt
ill see when i get to laptop
> unicorn:~$ ps -fp $$
> UID PIDPPID C STIME TTY TIME CMD
> greg 999 981 0 Mar26 pts/300:00:00 bash
>
> You appear to be using the "f" (BSD-ish) option which shows processes
> in a tree-like structure, but I can't tell from your pasted excerpt
> whether wpa_supplicant is actually the parent of the zombie, due to
> the lack of the PPID field.
>
> If it turns out that wpa_supplicant is the parent, then that's the
> responsible party, and that's where you should send your bug reports.
>
>
Re: forwarded weirdness report
please dont take it overly, accept free speech, and the lack of perfection thats there always everywhere anyway i will not read headpaining dumbshitt again, but wished a few words i motiv ate you to too, few words here few words there, .. greets On Wed, Mar 30, 2022 at 7:47 AM Lawrence Velázquez wrote: > > On Mar 30, 2022, at 1:37 AM, Alex fxmbsw7 Ratchev > wrote: > > > > your default of not allowing is weird > > > > seems 'allowing alias foreworders to speak' not good to you ? > > You're misrepresenting what I said and what Chris said. Read > messages more closely before you pop off. > > -- > vq
defuncted printf process when using wpa_supplicant
i do
wpa_supplicant -i"$if" -c<( printf %s\\n \
'network={' "ssid=\"$ssid\"" "psk=\"$pass\"" '}'
) &
{ sleep 3 ; dhclient "$if" ; } &
which is simply wpa_supplicant -iiface -c<( conf file printing )
it since years resuts in such : i think before it said printf defuncted
root 1528 0.0 0.0 12388 8656 ?S07:19 0:01
wpa_supplicant -iwlo1 -c/dev/fd/63
root 1530 0.0 0.0 0 0 ?Z07:19 0:00 \_
[3.wpa]
Re: forwarded weirdness report
your default of not allowing is weird seems 'allowing alias foreworders to speak' not good to you ? its norma; see peng not one THANK YOU and still unfriendly On Wed, Mar 30, 2022 at 7:35 AM Lawrence Velázquez wrote: > > On Mar 29, 2022, at 8:26 AM, Chris Elvidge > wrote: > > > > On 28/03/2022 22:00, Greg Wooledge wrote: > >> Or -- and I know this answer will be rejected, because it's too simple > >> and sensible -- stop using aliases in scripts. > > > > +1 > > > > Or could just stop answering questions about aliases in scripts > > Unfortunately this might simply allow the alias zealots to form an > unstoppable positive feedback loop. > > -- > vq > >
Re: forwarded weirdness report
ignorance priest ? On Tue, Mar 29, 2022, 14:27 Chris Elvidge wrote: > On 28/03/2022 22:00, Greg Wooledge wrote: > > > > Or -- and I know this answer will be rejected, because it's too simple > > and sensible -- stop using aliases in scripts. > > > > > > +1 > > Or could just stop answering questions about aliases in scripts > > -- > Chris Elvidge > England > > >
Re: forwarded weirdness report
On Mon, Mar 28, 2022 at 11:02 PM Greg Wooledge wrote: > On Mon, Mar 28, 2022 at 04:18:05PM -0400, Chet Ramey wrote: > > On 3/28/22 3:06 PM, Martin Schulte wrote: > > > on Mon, 28 Mar 2022 20:34:40 +0200 Alex fxmbsw7 Ratchev < > fxmb...@gmail.com> wrote: > > > > https://pastebin.com/raw/T7ZnFapt > > > > > > Here's a somewhat stripped down version: > > > > > > $ bash --noprofile --norc -i -c "echo \$BASH_VERSION; shopt -s > expand_aliases ; source <(echo \"alias x='echo hallo'\"); alias; x" > > > 5.1.4(1)-release > > > alias x='echo hallo' > > > bash: x: command not found > > > > OK, once more from the top. > > > > The argument to -c is a single command. Bash always reads a complete > command > > before executing any of it. The argument string is parsed into a > > compound command: a compound list. Since the entire compound list is > parsed > > before executing any of the commands it contains, the `x' is parsed as a > > simple command with no defined alias -- the parsing takes place before > > executing the `alias x=...' command. > > And here's a workaround: > > unicorn:~$ bash --noprofile --norc -i -c $'alias x="echo hallo"; x' > bash: x: command not found > unicorn:~$ bash --noprofile --norc -i -c $'alias x="echo hallo"\nx' > hallo > > Put a literal newline in the -c argument, rather than a semicolon. > > Or -- and I know this answer will be rejected, because it's too simple > and sensible -- stop using aliases in scripts. > well mate, i must argue here aliases, are the smallest part of replicatinng code, without function spawn and arg parsing overheat if u cant handle em, u stay away from em, like u do i need em, basic important big part of coding languages against dup code
Re: forwarded weirdness report
ok thanks for cool explaintion i may beg for more intelligent, more 'human readable format' supporting such as, code is there, that it doesnt run is implentation fault however u aint alone gawk parser in combination with djb tcpserver results ( ill try again soon ) in big fails in proceeding after found RS, cause, the parser implentation misses it, cause its bad coded not-per-char match ( just some invalid ) a main gawk coder said, everything should get rewritten, and it wont, so just l greets, bless On Mon, Mar 28, 2022, 22:18 Chet Ramey wrote: > On 3/28/22 3:06 PM, Martin Schulte wrote: > > Hello, > > > > on Mon, 28 Mar 2022 20:34:40 +0200 Alex fxmbsw7 Ratchev < > fxmb...@gmail.com> wrote: > >> https://pastebin.com/raw/T7ZnFapt > >> > >> about inconsitency, about chets 'uh no bugs' > >> > >> ive experienced this and such x times already ( got better, this is not > my > >> code ) > > > > Here's a somewhat stripped down version: > > > > $ bash --noprofile --norc -i -c "echo \$BASH_VERSION; shopt -s > expand_aliases ; source <(echo \"alias x='echo hallo'\"); alias; x" > > 5.1.4(1)-release > > alias x='echo hallo' > > bash: x: command not found > > OK, once more from the top. > > The argument to -c is a single command. Bash always reads a complete > command before executing any of it. The argument string is parsed into a > compound command: a compound list. Since the entire compound list is parsed > before executing any of the commands it contains, the `x' is parsed as a > simple command with no defined alias -- the parsing takes place before > executing the `alias x=...' command. > > -- > ``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: forwarded weirdness report
well irc recalled its cause aliases expand after one newline what the outdated ... On Mon, Mar 28, 2022 at 8:34 PM Alex fxmbsw7 Ratchev wrote: > https://pastebin.com/raw/T7ZnFapt > > about inconsitency, about chets 'uh no bugs' > > ive experienced this and such x times already ( got better, this is not my > code ) >
forwarded weirdness report
https://pastebin.com/raw/T7ZnFapt about inconsitency, about chets 'uh no bugs' ive experienced this and such x times already ( got better, this is not my code )
Re: parameter expansion null check fails for arrays when [*] or [@] is used
there is nothing but a simple str minus str, results in null string
some, internal check, to make null nothing strings marked non existing, is
up to you to code, and yet such doesnt exist much i think in sh bashism
On Wed, Mar 23, 2022, 12:44 Greg Wooledge wrote:
> On Wed, Mar 23, 2022 at 01:48:48AM -0700, L A Walsh wrote:
> > On 2022/03/23 00:25, Ilkka Virta wrote:
> > > The POSIX phraseology is that "null" means the empty string.
> >
> >POSIX phraseology applies to the POSIX language.
> >
> > In 'C'
> >
> > char *s = NULL
> > is not the same as
> > char *s="";
>
> Yes, we know this. But this is bug-bash, so we're discussing the shell
> known as bash. Bash doesn't have pointers, so it cannot have NULL pointers
> either.
>
> Would I have chosen to use the word "null" to mean "empty string" in
> the shell's documentation, if I were writing it? No. I wouldn't have,
> because it's an overloaded word with very different meanings in different
> contexts (cf. SQL's NULL, and the ASCII NUL character).
>
> But as it happens, the writers of the POSIX standards *did* use that
> word in some places, and so we have to live with it.
>
> unicorn:~$ man 1p sh | grep -i null
> argument. If FCEDIT is null or unset, ed shall be used as
> the
> ables that are unset or null. (See the Base Definitions
> vol‐
>
> Back to the original topic, I have absolutely no idea what "${a[@]:+word}"
> is supposed to do. It doesn't make any sense to me, and I would never
> write that in a script. So, I have no comments about it in terms of
> this bug report.
>
>
Re: for loop over parameter expansion of array can miss resulted empty list
i solve this by shopt -s nullglob
On Sun, Mar 20, 2022, 22:07 Alexey via Bug reports for the GNU Bourne Again
SHell wrote:
> Hello.
>
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -Wall
> uname output: Linux alex 5.16.0-3-amd64 #1 SMP PREEMPT Debian 5.16.11-1
> (2022-02-25) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
>If use 'Parameter Expansion', for example 'Remove matching suffix
> pattern', on array and try to iterate over expansion result with for
> loop, may occur that loop body will not be executed at all.
>
> Repeat-By:
>Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
>Result: none
>Expected result: i is ''
>
> Expected behavior:
>like for an array with empty element
>Code: x=(""); for i in "${x[@]}"; do echo "i is '$i'"; done
>Result: i is ''
>
>another example, show that problems occurs only with empty resulted
> list
>Code: x=("/" "//"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
>Result: i is ''
>i is '/'
>
>
> Regards,
> Alexey
>
>
Re: BASH_COMMAND should be set before PS0
a small cosmetic workaround fix trap 'cmd=$BASH_COMMAND' DEBUG PS1='$cmd' On Sat, Mar 19, 2022 at 6:12 PM Taqras via Bug reports for the GNU Bourne Again SHell wrote: > 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 > -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' > -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' > -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS > uname output: Linux EliteBook 5.16.15-arch1-1 #1 SMP PREEMPT Thu, 17 Mar > 2022 00:30:09 + x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.1 > Patch Level: 16 > Release Status: release > > Description: > PS0: >The value of this parameter is expanded like PS1 and displayed by >interactive shells after reading a command and before the command is >executed. > BASH_COMMAND: >The command currently being executed or about to be executed, unless >the shell is executing a command as the result of a trap, in which >case it is the command executing at the time of the trap. If >BASH_COMMAND is unset, it loses its special properties, >even if it is subsequently reset. > PROBLEM: >By the time PS0 is displayed, BASH_COMMAND is still set to the >previous command, not the command about to be executed. > >And that's just about the only problem: >Thank you very much for your good work!!! > > Repeat-By: > PS0="$BASH_COMMAND" > > Fix: > Assign BASH_COMMAND before expanding PS0 >
Re: declare -x non-exportable variable types
On Fri, Feb 25, 2022 at 8:52 PM Chet Ramey wrote: > On 2/25/22 12:55 PM, Léa Gris wrote: > > Le 25/02/2022 à 16:49, Chet Ramey écrivait : > > > >> You can't export array variables, period. You can't export attributes, > >> only variable names and values. You still can't export attributes. > There > >> is no way to export attributes > > > > Chet, I heard you, I understood it and I knew it before, while I was > > writing my message, and still now. > > > > It feels like that you were either in a bad mood or that I didn't manage > to > > express my remarks and thoughts as clearly as I would have liked. > > OK. I don't think my response was especially tense (now, terse, maybe). I > simply disagree with much of your premise. > > > Now that you and I are, were and still are (I reassure you) in absolute > > agreement with: "Bash variable attributes and, or arrays are > incompatible > > with environment variables" (undisputed fact)... > > Variables have names, values, and attributes. Environment variables don't > have enough information to contain all three (or two, in the case of > arrays, without some special encoding). > you map those as extension in free space, just like you do with your function to children passment my only comment to this > > > > Is it possible that: if these variables are passed explicitly as > > environment variables with -x or export : > > > > - Either Bash returns an error because of "variable flags are > incompatible > > with the environment, and it's a mistake to export Bash variables with > > flags", rather than having different behaviours (pass value, nothing, > > name...) based on the original Bash variable flags/type? > > But you have not shown such `different behaviors'. In the case of array > variables, not exporting them is a conscious choice based on the issues > encoding the values, and that is documented. Is that what you mean? > > > > > - Or that Bash should now be able to "convert" the value as it does now, > > but in a more consistent way? > > I simply don't see the inconsistency you claim is there. Bash exports names > and values for variables to which you assign the export attribute. > > > - Or that the documentation contains an explicit description of what > > happens when one tries to export a Bash variable with flags/types (even > > just documented as: "The result of exporting Bash variables with > attributes > > is indeterminate"), which might be an appropriate clarification? > > OK, what's indeterminate about it? I showed how the behavior from your > first message was all consistent. > > -- > ``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 completion mangles file names with newlines
besides not running newest bash On Wed, Feb 23, 2022, 17:36 Ian! D. Allen wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security > uname output: Linux ubuntu20-04 5.13.0-30-generic #33~20.04.1-Ubuntu SMP > Mon Feb 7 14:25:10 UTC 2022 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: > BASH completion cannot correctly handle file names containing > newline characters. > > Repeat-By: > # First, get a shell with no completion loaded and show it working: > $ bash --norc > bash-5.0$ ls -b > one\ntwo\nthree\nfour\nfive\nsix > bash-5.0$ xxx 'one > two > three > four > five > six' > bash-5.0$ touch foo > bash-5.0$ xxx > foo one^Jtwo^Jthree^Jfour^Jfive^Jsix > bash-5.0$ xxx 'one > two > three > four > five > six' > > # Now, load the completion scripts and watch it break: > bash-5.0$ source /usr/share/bash-completion/bash_completion > bash-5.0$ ls -b > foo one\ntwo\nthree\nfour\nfive\nsix > bash-5.0$ xxx > five foofour onesixthree two > bash-5.0$ xxx o > five four onesixthree two > > # The last two completions are garbage. > # The file name is being split on newlines. > > -- > | Ian! D. Allen, BA-Psych, MMath-CompSci idal...@idallen.ca Ottawa CANADA > | Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca > | Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com > | Improve democracy www.fairvote.ca and defend digital freedom www.eff.org > >
Re: bash completion mangles file names with newlines
as far i know is the bash compl external and buggy i trash it since 2002 On Wed, Feb 23, 2022, 17:36 Ian! D. Allen wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security > uname output: Linux ubuntu20-04 5.13.0-30-generic #33~20.04.1-Ubuntu SMP > Mon Feb 7 14:25:10 UTC 2022 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: > BASH completion cannot correctly handle file names containing > newline characters. > > Repeat-By: > # First, get a shell with no completion loaded and show it working: > $ bash --norc > bash-5.0$ ls -b > one\ntwo\nthree\nfour\nfive\nsix > bash-5.0$ xxx 'one > two > three > four > five > six' > bash-5.0$ touch foo > bash-5.0$ xxx > foo one^Jtwo^Jthree^Jfour^Jfive^Jsix > bash-5.0$ xxx 'one > two > three > four > five > six' > > # Now, load the completion scripts and watch it break: > bash-5.0$ source /usr/share/bash-completion/bash_completion > bash-5.0$ ls -b > foo one\ntwo\nthree\nfour\nfive\nsix > bash-5.0$ xxx > five foofour onesixthree two > bash-5.0$ xxx o > five four onesixthree two > > # The last two completions are garbage. > # The file name is being split on newlines. > > -- > | Ian! D. Allen, BA-Psych, MMath-CompSci idal...@idallen.ca Ottawa CANADA > | Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca > | Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com > | Improve democracy www.fairvote.ca and defend digital freedom www.eff.org > >
Re: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'
i have observed many non on clean reproducable things over time On Tue, Feb 22, 2022, 22:00 Chet Ramey wrote: > On 2/22/22 3:38 PM, Benoit Lacelle wrote: > > bash-5.1# echo $PATH > > > > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > > > > bash-5.1# ls /usr/local/bin/npm > > > > */usr/local/bin/npm > > > > -> yes, there is such a file in a folder described by $PATH* > > I don't know what else to tell you. I can't reproduce it using ostensibly > the same environment you have, so I can't be much help from here. > > 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/ > >
Re: Long variable value get corrupted sometimes
does the data contain \0 null bytes On Wed, Feb 16, 2022 at 11:20 AM David wrote: > On Wed, 16 Feb 2022 at 19:38, Daniel Qian wrote: > > > I encountered a problem that long variable value get corrupted sometimes. > > > A UTF-8 encoded file containing a lot of Chinese characters, file size > ~35K. > > > FOO=$(cat /tmp/foo.txt) > > Hi, this looks like something that was recently fixed, perhaps > you can try this patch: > https://savannah.gnu.org/patch/?10035 > >
Re: the "-e" command line argument is not recognized
On Wed, Feb 16, 2022 at 9:59 AM Andreas Schwab wrote: > On Feb 16 2022, Viktor Korsun wrote: > > > runme.sh > > #!/bin/bash > > echo $0 > > echo $1 > > echo $2 > > echo $3 > > echo $4 > > echo $5 > > echo $6 > > Don't use echo to print unknown text. Use printf instead, which can > handle this correctly. Also, don't forget to quote properly. > > printf "%s\n" "$4" > printf '%s args\n' $# printf %s\\n "$@" > > > > > command: > > ./runme.sh -q -w -e -r -t -y > > > > produced output: > > ./get_env.sh > > -q > > -w > > > > $ help echo > echo: echo [-neE] [arg ...] > Write arguments to the standard output. > > Display the ARGs, separated by a single space character and followed > by a > newline, on the standard output. > > Options: > -ndo not append a newline > -eenable interpretation of the following backslash escapes > -Eexplicitly suppress interpretation of backslash escapes > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." > >
Re: Sus behaviour when cmd string ends with single backslash
i like the currently showed behavior of '\' parsed as arg no need to error .. if u meant that, .. On Mon, Feb 14, 2022 at 11:17 PM Chet Ramey wrote: > On 2/13/22 3:15 PM, vzvz...@gmail.com wrote: > > > Bash Version: 5.0 > > Patch Level: 17 > > Release Status: release > > > > Description: > > > > Background > > -- > > > > Commit a0c0a00fc419b7bc08202a79134fcd5bc0427071 (bash-4.4) introduced a > change in parse.y with following documentation in the change logs: > > > > parse.y > > - shell_getc: if bash is reading input from a string that ends > with an > > unquoted backslash, add another backslash instead of a newline, > since > > the backslash and newline will disappear in normal processing. > Fixes > > bug with `bash -c 'eval \\; echo y' ' skipping the eval command > and > > setting incorrect exit status, and `bash -ic 'eval \\; echo y' ' > > seeing EOF on empty line and exiting before the echo. Keep > track of > > backslash state with last_was_backslash; set in char reading > loop. > > Fixes bug reported by Eduardo A. Bustamante López < > dual...@gmail.com> > > > > The new code in parse.y > > > > /* Don't add a newline to a string that ends with a backslash if > we're > >going to be removing quoted newlines, since that will eat the > >backslash. Add another backslash instead (will be removed by > >word expansion). */ > > if (bash_input.type == st_string && expanding_alias() == 0 && > last_was_backslash && c == EOF && remove_quoted_newline) > > shell_input_line[shell_input_line_len] = '\\'; > > else > > shell_input_line[shell_input_line_len] = '\n'; > > shell_input_line[shell_input_line_len + 1] = '\0'; > > > > > > This specific change is also there in commit > 0385211bb5cb01e0259c64ec2c5cc6337d4e215c on a development branch. > > > > Observed vs. expected behaviour > > --- > > > > The mentioned bug is indeed fixed by this change. However, in case of > another edge case following new behaviour is observable: > > > > $ bash -c 'echo \' > > \ > > $ # backslash appears on output > > I think the behavior of a word consisting only of a backslash is officially > unspecified. > > It's not a quote character -- there's nothing to quote -- so it's not > removed by quote removal. > > In general, I think it's better to err on the side of preserving output > here. > > Existing shell behavior varies, so you can't really count on anything. > > -- > ``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: Sus behaviour when cmd string ends with single backslash
On Sun, Feb 13, 2022, 22:23 wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security > uname output: Linux zoli-linux 5.13.0-28-generic #31~20.04.1-Ubuntu SMP > Wed Jan 19 14:08:10 UTC 2022 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: > > Background > -- > > Commit a0c0a00fc419b7bc08202a79134fcd5bc0427071 (bash-4.4) introduced a > change in parse.y with following documentation in the change logs: > > parse.y > - shell_getc: if bash is reading input from a string that ends > with an > unquoted backslash, add another backslash instead of a newline, > since > the backslash and newline will disappear in normal processing. > Fixes > bug with `bash -c 'eval \\; echo y' ' skipping the eval command > and > setting incorrect exit status, and `bash -ic 'eval \\; echo y' ' > seeing EOF on empty line and exiting before the echo. Keep > track of > backslash state with last_was_backslash; set in char reading > loop. > Fixes bug reported by Eduardo A. Bustamante López < > dual...@gmail.com> > > The new code in parse.y > > /* Don't add a newline to a string that ends with a backslash if > we're > going to be removing quoted newlines, since that will eat the > backslash. Add another backslash instead (will be removed by > word expansion). */ > if (bash_input.type == st_string && expanding_alias() == 0 && > last_was_backslash && c == EOF && remove_quoted_newline) > shell_input_line[shell_input_line_len] = '\\'; > else > shell_input_line[shell_input_line_len] = '\n'; > shell_input_line[shell_input_line_len + 1] = '\0'; > > > This specific change is also there in commit > 0385211bb5cb01e0259c64ec2c5cc6337d4e215c on a development branch. > > Observed vs. expected behaviour > --- > > The mentioned bug is indeed fixed by this change. However, in case of > another edge case following new behaviour is observable: > > $ bash -c 'echo \' > \ > $ # backslash appears on output > bash -c recognized a backslash due to smarter input checking as arg instead of newline break The behaviour before the change was following: > > $ bash -c 'echo \' > > $ # no output > bash -c recognized \ \n eof do you know, $' foo \' bar \' ' to preseeve 's if u dont This behaviour is observable since 4.4 up to the most current released > version (5.1). > > I am not sure what is the correct behaviour here. My best guess is, that > the single backslash at the end of the string should not be printed, > because (bash man page): > > Quote Removal >After the preceding expansions, all unquoted occurrences of the > characters \, ', and " that did not result >from one of the above expansions are removed. > > This behaviour would be consistent with the very same command took from a > script: > > $ hexdump -C echo-with-newline.sh > 65 63 68 6f 20 5c 0a |echo \.| > 0007 > $ hexdump -C echo-without-newline.sh > 65 63 68 6f 20 5c |echo \| > 0006 > $ bash echo-with-newline.sh > > $ bash echo-without-newline.sh > > $ # no output in both cases > > Repeat-By: > See commands in the description. > > >
Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
On Tue, Feb 8, 2022 at 12:09 AM Ángel wrote: > > On 2022-02-07 at 11:55 +0100, Alex fxmbsw7 Ratchev wrote: > > > > however my solution still stays > > > > you just use memory locations instead of c strings > > > > and those entries in memory are of course of known length, before > > > > setting and all is fine > > > > > > "Your" solution is decades old. Everyone knows how Pascal-style > > > strings work. This is not cutting-edge computer science. > > > > i dunno what pascal strings are, sorry > > Pascal strings refers to strings prefixed with their length: > https://en.wikipedia.org/wiki/String_(computer_science)#Length-prefixed > > Basically, what you were proposing. i see, thank you for good explaintion ( in your words not url ) > > > And as Veláquez said, it's ingenuous propose a solution nobody else > asked for, expecting others to spend the effort of actually > implementing it (plus the critics of their result, such as a limitation > on the string length, or of wasted memory for every pointer). well as im an outsuder i agree else, i can just say, rather keep the nulls you kept the \1'en and \xff :)) ( yeah not you, the c library language or whatever ) greets
Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
On Mon, Feb 7, 2022 at 7:45 AM Lawrence Velázquez wrote: > > On Mon, Feb 7, 2022, at 1:26 AM, Alex fxmbsw7 Ratchev wrote: > > well i saw now, printf a char of "\0" results in 0 bytes out to wc -c > > % /usr/bin/printf '\0' | wc -c >1 > > > > however my solution still stays > > you just use memory locations instead of c strings > > and those entries in memory are of course of known length, before setting > > and all is fine > > "Your" solution is decades old. Everyone knows how Pascal-style > strings work. This is not cutting-edge computer science. i dunno what pascal strings are, sorry > > of course this means to not use these fauly 'c strings', but a self > > coded solution > > As Greg already mentioned, such a system requires converting back > to C strings for system calls and other external APIs. It's not > insurmountable, but it's more involved than just swapping all your > char * to my_string or whatever hard work this way i see sorry, thanks. > > I repeat: > > >> It's so simple that you should have no problem converting the entire > >> bash codebase to Pascal-style strings yourself. We'll wait. > > > -- > vq
Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
On Mon, Feb 7, 2022 at 6:19 AM Lawrence Velázquez wrote: > > On Sun, Feb 6, 2022, at 11:53 PM, Alex fxmbsw7 Ratchev wrote: > > On Mon, Feb 7, 2022 at 12:02 AM Greg Wooledge wrote: > >> There are other programming languages besides bash. Some of them can > >> store NUL bytes internally, either by encoding and decoding them on the > >> fly, or by not using C-style strings internally (which means any system > >> calls require encoding/decoding the internal strings to C-style strings). > > > > i am not sure, but, tell me > > 'c strings' is a problem due to internal function handling with static \0 > > eof > > while 'c strings' can store null bytes no ? ( tell me if this is true > > or not plz ) > > It is not true. C strings are terminated by NUL. well i saw now, printf a char of "\0" results in 0 bytes out to wc -c however my solution still stays you just use memory locations instead of c strings and those entries in memory are of course of known length, before setting and all is fine i mean you have 3 strings, "abc" "\0\0\0" and "something" again you wanna store those, you know those, they length, to map em with an index of length to memory and access em therefore they must be in some memory cluster that can expand of course how to try to explain you read 3 bytes abc u map em, u read 3 bytes 0 u map em, and so they also can be accessed of course this means to not use these fauly 'c strings', but a self coded solution i must do one, next thing when i get to .c cause i __do not__ wanna miss \0's > > then if, its up to the coding buddies to self code > > How generous of you to volunteer other people's time and effort. > > > > its so simple: > > you have always static length strings simply, u conunt and know the > > length of every msg used, and so u can separate right > > isnt it so simple ? > > It's so simple that you should have no problem converting the entire > bash codebase to Pascal-style strings yourself. We'll wait. > > > >> I urge you to learn one of these other languages, and use it. > > > > i cant read others docs it seems buddy, it budds mee, its like the web > > docs about shell scripting, as you i and i wrote on our pages, its > > very invalid > > and so i cant learn a new language sorry > > Tragic. > > > -- > vq
Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
On Mon, Feb 7, 2022 at 3:37 AM Chet Ramey wrote: > > On 2/6/22 5:11 PM, Alex fxmbsw7 Ratchev wrote: > > i just have a small question here > > the dropping of null bytes is no friend of me and i understand you're > > there to skip it instead of process, which results in null bytes gone > > which is not much of an use > > > > can't these \0 bytes be encoded at least when a utf8 locale is used as > > \u0 instead of dropping ? and a null, ... just > > prefix the utf 8 encoding chars to the null > > and they'd be safely maybe still here > > OK, say they're still there. What use are they? What are you going to do > with them? it'd be a big wonder to me this is about data preservance, aka not mangling if the nulls are present, internal variables can be used for any kind of input rather than only files its only a plus to have em -- > ``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: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
On Mon, Feb 7, 2022 at 12:02 AM Greg Wooledge wrote: > > On Sun, Feb 06, 2022 at 11:11:43PM +0100, Alex fxmbsw7 Ratchev wrote: > > [[ Regarding nul bytes discarded by command substitution ]] > > can't these \0 bytes be encoded at least when a utf8 locale is used as > > \u0 instead of dropping ? and a null, ... just > > prefix the utf 8 encoding chars to the null > > and they'd be safely maybe still here > > There are other programming languages besides bash. Some of them can > store NUL bytes internally, either by encoding and decoding them on the > fly, or by not using C-style strings internally (which means any system > calls require encoding/decoding the internal strings to C-style strings). i am not sure, but, tell me 'c strings' is a problem due to internal function handling with static \0 eof while 'c strings' can store null bytes no ? ( tell me if this is true or not plz ) then if, its up to the coding buddies to self code its so simple: you have always static length strings simply, u conunt and know the length of every msg used, and so u can separate right isnt it so simple ? > I urge you to learn one of these other languages, and use it. i cant read others docs it seems buddy, it budds mee, its like the web docs about shell scripting, as you i and i wrote on our pages, its very invalid and so i cant learn a new language sorry > Bash is a shell, not a full general-purpose programming language. It's > not suited to all tasks. Many other languages are *better* suited to > various tasks. Using the best language for each task will make your > life easier. my life easier .. aha thats a big joke seriously i agree with the logic, of not using a worse than suited language for a task but sadly, its no wunschkonzert where i select oh this one language outta 1k anagues no i only do bash and gawk , due to bad written docs , not itself i also understand your knows about other languages so you ad em but bash is a major one and somewhen get as big as its supposed to be just like others will i see a future for me only when i self .c code my own toolset which i cant aha :))
Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
a replacement sequence to null bytes i would find a solution to null bytes no i didnt understand these posts of these emails but i am just concerned about the null bytes not being dropped On Sun, Feb 6, 2022 at 11:16 PM Alex fxmbsw7 Ratchev wrote: > > im sorry i didnt realize it would just prefix to null byte, which uses > nullbyte, so it wont work > cheers > > On Sun, Feb 6, 2022 at 11:11 PM Alex fxmbsw7 Ratchev > wrote: > > > > i just have a small question here > > the dropping of null bytes is no friend of me and i understand you're > > there to skip it instead of process, which results in null bytes gone > > which is not much of an use > > > > can't these \0 bytes be encoded at least when a utf8 locale is used as > > \u0 instead of dropping ? and a null, ... just > > prefix the utf 8 encoding chars to the null > > and they'd be safely maybe still here > > > > just asking.. > > > > On Sun, Feb 6, 2022 at 6:38 PM Chet Ramey wrote: > > > > > > On 2/5/22 9:41 PM, L A Walsh wrote: > > > > > > > That's debatable, BTW, as I was reminded of a similar > > > > passthrough of what one might call 'invalid input' w/o warning, > > > > resulting in code that worked in a specific circumstance to a change > > > > in bash issuing a warning that resulted in breaking code, that, at that > > > > point, worked as expected. > > > > > > Memory is a tricky thing. This statement -- you've made it twice -- got me > > > wondering what you might be referring to, so I went digging. > > > > > > > > > > Specifically, it involved reading a value typically in the range > > > > 50 <=x <=150 from an active file (like a value from /proc that varies > > > > based on OS internal values) where the data was stored in a > > > > quad, or Little-Endian DWORD value, so the value was in the the > > > > 2 least significant bytes with the most significant bytes following > > > > (in a higher position) in memory, like: > > > > Byte# => 00 01 02 03, for value 100 decimal: > > > > hex => 64 00 00 00 > > > > > > > > The working code expected to see 0x64 followed by 0x00 which it > > > > used as string terminator. > > > > > Chet "fixed" this silent use of 0x00 as a string terminator to no longer > > > > ignore it, but have bash issue a warning message, which caused the > > > > "read < fn" to fail and return 0 instead of the ascii character 'd', > > > > which > > > > the program had interpret as the DPI value of the user's screen. > > > > > > So it seems like you've conflated two different things. The first is the > > > command substitution warning about dropping NULL bytes from 2016: > > > > > > https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00015.html > > > > > > which I talked about a couple of days ago: > > > > > > https://lists.gnu.org/archive/html/bug-bash/2022-02/msg00054.html > > > > > > The second is a change from back in 2011 (bash-4.2 days) that changed bash > > > to drop NULL bytes in the read builtin: > > > > > > https://lists.gnu.org/archive/html/bug-bash/2011-11/msg00136.html > > > > > > One of my messages in that thread contains a quickie survey of other > > > shells' behavior here. The change is in line with what other shells do. > > > > > > > > > > It took some debugging and hack arounds to find another way to access > > > > the data. So what some might have called silent data corruption because > > > > bash silently passed through the nul terminated datum as a string > > > > terminator, my program took as logical behavior. I complained about > > > > the change, > > > > > > Where? Since this is the opposite of what happened in the command > > > substitution case, I'm assuming you mean the read change from 2011. You > > > didn't participate in the original discussion, and I'm just not inclined > > > to go digging around the archives for it. > > > > > > > remarking that if bash was going to sanitize returned values > > > > (in that case checking for what should have been an ascii value with NUL > > > > not being in the allowed value of string characters), that bash might > > > > also be saddled with checking for invalid Unicode sequences and warning > > > > about > > > > them as well, regardless of the source of the corruption, some programs > > > > might expect to get a raw byte sequence rather than some encoded form > > > > with the difference in interpretation causing noticeable bugs. > > > > > > You might actually have said something like this at some point. > > > > > > I'd prefer to think your memory has conflated these two things, and that > > > this is how you remember it. That's better than the alternative. > > > > > > -- > > > ``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: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
im sorry i didnt realize it would just prefix to null byte, which uses nullbyte, so it wont work cheers On Sun, Feb 6, 2022 at 11:11 PM Alex fxmbsw7 Ratchev wrote: > > i just have a small question here > the dropping of null bytes is no friend of me and i understand you're > there to skip it instead of process, which results in null bytes gone > which is not much of an use > > can't these \0 bytes be encoded at least when a utf8 locale is used as > \u0 instead of dropping ? and a null, ... just > prefix the utf 8 encoding chars to the null > and they'd be safely maybe still here > > just asking.. > > On Sun, Feb 6, 2022 at 6:38 PM Chet Ramey wrote: > > > > On 2/5/22 9:41 PM, L A Walsh wrote: > > > > > That's debatable, BTW, as I was reminded of a similar > > > passthrough of what one might call 'invalid input' w/o warning, > > > resulting in code that worked in a specific circumstance to a change > > > in bash issuing a warning that resulted in breaking code, that, at that > > > point, worked as expected. > > > > Memory is a tricky thing. This statement -- you've made it twice -- got me > > wondering what you might be referring to, so I went digging. > > > > > > > Specifically, it involved reading a value typically in the range > > > 50 <=x <=150 from an active file (like a value from /proc that varies > > > based on OS internal values) where the data was stored in a > > > quad, or Little-Endian DWORD value, so the value was in the the > > > 2 least significant bytes with the most significant bytes following > > > (in a higher position) in memory, like: > > > Byte# => 00 01 02 03, for value 100 decimal: > > > hex => 64 00 00 00 > > > > > > The working code expected to see 0x64 followed by 0x00 which it > > > used as string terminator. > > > > Chet "fixed" this silent use of 0x00 as a string terminator to no longer > > > ignore it, but have bash issue a warning message, which caused the > > > "read < fn" to fail and return 0 instead of the ascii character 'd', which > > > the program had interpret as the DPI value of the user's screen. > > > > So it seems like you've conflated two different things. The first is the > > command substitution warning about dropping NULL bytes from 2016: > > > > https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00015.html > > > > which I talked about a couple of days ago: > > > > https://lists.gnu.org/archive/html/bug-bash/2022-02/msg00054.html > > > > The second is a change from back in 2011 (bash-4.2 days) that changed bash > > to drop NULL bytes in the read builtin: > > > > https://lists.gnu.org/archive/html/bug-bash/2011-11/msg00136.html > > > > One of my messages in that thread contains a quickie survey of other > > shells' behavior here. The change is in line with what other shells do. > > > > > > > It took some debugging and hack arounds to find another way to access > > > the data. So what some might have called silent data corruption because > > > bash silently passed through the nul terminated datum as a string > > > terminator, my program took as logical behavior. I complained about > > > the change, > > > > Where? Since this is the opposite of what happened in the command > > substitution case, I'm assuming you mean the read change from 2011. You > > didn't participate in the original discussion, and I'm just not inclined > > to go digging around the archives for it. > > > > > remarking that if bash was going to sanitize returned values > > > (in that case checking for what should have been an ascii value with NUL > > > not being in the allowed value of string characters), that bash might > > > also be saddled with checking for invalid Unicode sequences and warning > > > about > > > them as well, regardless of the source of the corruption, some programs > > > might expect to get a raw byte sequence rather than some encoded form > > > with the difference in interpretation causing noticeable bugs. > > > > You might actually have said something like this at some point. > > > > I'd prefer to think your memory has conflated these two things, and that > > this is how you remember it. That's better than the alternative. > > > > -- > > ``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: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
i just have a small question here the dropping of null bytes is no friend of me and i understand you're there to skip it instead of process, which results in null bytes gone which is not much of an use can't these \0 bytes be encoded at least when a utf8 locale is used as \u0 instead of dropping ? and a null, ... just prefix the utf 8 encoding chars to the null and they'd be safely maybe still here just asking.. On Sun, Feb 6, 2022 at 6:38 PM Chet Ramey wrote: > > On 2/5/22 9:41 PM, L A Walsh wrote: > > > That's debatable, BTW, as I was reminded of a similar > > passthrough of what one might call 'invalid input' w/o warning, > > resulting in code that worked in a specific circumstance to a change > > in bash issuing a warning that resulted in breaking code, that, at that > > point, worked as expected. > > Memory is a tricky thing. This statement -- you've made it twice -- got me > wondering what you might be referring to, so I went digging. > > > > Specifically, it involved reading a value typically in the range > > 50 <=x <=150 from an active file (like a value from /proc that varies > > based on OS internal values) where the data was stored in a > > quad, or Little-Endian DWORD value, so the value was in the the > > 2 least significant bytes with the most significant bytes following > > (in a higher position) in memory, like: > > Byte# => 00 01 02 03, for value 100 decimal: > > hex => 64 00 00 00 > > > > The working code expected to see 0x64 followed by 0x00 which it > > used as string terminator. > > > Chet "fixed" this silent use of 0x00 as a string terminator to no longer > > ignore it, but have bash issue a warning message, which caused the > > "read < fn" to fail and return 0 instead of the ascii character 'd', which > > the program had interpret as the DPI value of the user's screen. > > So it seems like you've conflated two different things. The first is the > command substitution warning about dropping NULL bytes from 2016: > > https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00015.html > > which I talked about a couple of days ago: > > https://lists.gnu.org/archive/html/bug-bash/2022-02/msg00054.html > > The second is a change from back in 2011 (bash-4.2 days) that changed bash > to drop NULL bytes in the read builtin: > > https://lists.gnu.org/archive/html/bug-bash/2011-11/msg00136.html > > One of my messages in that thread contains a quickie survey of other > shells' behavior here. The change is in line with what other shells do. > > > > It took some debugging and hack arounds to find another way to access > > the data. So what some might have called silent data corruption because > > bash silently passed through the nul terminated datum as a string > > terminator, my program took as logical behavior. I complained about > > the change, > > Where? Since this is the opposite of what happened in the command > substitution case, I'm assuming you mean the read change from 2011. You > didn't participate in the original discussion, and I'm just not inclined > to go digging around the archives for it. > > > remarking that if bash was going to sanitize returned values > > (in that case checking for what should have been an ascii value with NUL > > not being in the allowed value of string characters), that bash might > > also be saddled with checking for invalid Unicode sequences and warning > > about > > them as well, regardless of the source of the corruption, some programs > > might expect to get a raw byte sequence rather than some encoded form > > with the difference in interpretation causing noticeable bugs. > > You might actually have said something like this at some point. > > I'd prefer to think your memory has conflated these two things, and that > this is how you remember it. That's better than the alternative. > > -- > ``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: i had a read not work..
no i couldnt reproduce it when my script after long time a bit began working i tried \\n and it worked im sorry there was also when IFS=$'\1' issue i couldnt fix but that may also be code error of my fault =)) peace On Sun, Feb 6, 2022 at 2:16 AM Alex fxmbsw7 Ratchev wrote: > > well, im currently coding it as one file ( it results in same code as before ) > then i can change the \0 to \n and see if it appears again > then i can post > > thank you much > > On Sun, Feb 6, 2022 at 2:07 AM Greg Wooledge wrote: > > > > On Sun, Feb 06, 2022 at 01:43:57AM +0100, Alex fxmbsw7 Ratchev wrote: > > > this is on a friends os x, where brew install bash and gawk, resulted > > > in good versions > > > > > > i tried > > > > > > gawk ' print ; fflush' > > > > > > with a read -r varname, also read -r -d $'\n' varname > > > > > > it never_ returned results > > > -d '' worked fine > > > > You're going to have to show us the actual command that you ran, and > > the result that you got. > >
Re: i had a read not work..
well, im currently coding it as one file ( it results in same code as before ) then i can change the \0 to \n and see if it appears again then i can post thank you much On Sun, Feb 6, 2022 at 2:07 AM Greg Wooledge wrote: > > On Sun, Feb 06, 2022 at 01:43:57AM +0100, Alex fxmbsw7 Ratchev wrote: > > this is on a friends os x, where brew install bash and gawk, resulted > > in good versions > > > > i tried > > > > gawk ' print ; fflush' > > > > with a read -r varname, also read -r -d $'\n' varname > > > > it never_ returned results > > -d '' worked fine > > You're going to have to show us the actual command that you ran, and > the result that you got. >
i had a read not work..
this is on a friends os x, where brew install bash and gawk, resulted in good versions i tried gawk ' print ; fflush' with a read -r varname, also read -r -d $'\n' varname it never_ returned results -d '' worked fine
Re: Incorrect alias expansion within command substitution
yea sorry i accept it doesnt work .. On Sat, Feb 5, 2022, 22:31 Chet Ramey wrote: > On 2/5/22 3:54 PM, Alex fxmbsw7 Ratchev wrote: > > it would make the whole work at alias level > > alias (symbolic) 1=$(( 2=1+2 3=+ 4=1+2 5=)) > > 1 2 3 4 5 > > works > > [i wish] > > We need an intervention here. > > -- > ``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: Incorrect alias expansion within command substitution
meant in more reasonable complicated codes they are more useufl
On Sat, Feb 5, 2022 at 9:54 PM Alex fxmbsw7 Ratchev wrote:
>
> it would make the whole work at alias level
> alias (symbolic) 1=$(( 2=1+2 3=+ 4=1+2 5=))
> 1 2 3 4 5
> works
> [i wish]
>
> On Sat, Feb 5, 2022 at 9:46 PM Chet Ramey wrote:
> >
> > On 2/5/22 3:44 PM, Alex fxmbsw7 Ratchev wrote:
> > > On Sat, Feb 5, 2022 at 9:39 PM Alex fxmbsw7 Ratchev
> > > wrote:
> > >>
> > >> On Sat, Feb 5, 2022 at 7:55 PM Chet Ramey wrote:
> > >>>
> > >>> On 2/4/22 6:17 PM, Alex fxmbsw7 Ratchev wrote:
> > >>>> what about this viewing point
> > >>>> aliases can start, $(('s, but not end... this is unlogic
> > >>>
> > >>> Well, I don't know about `unlogic' but there's an understanding deficit,
> > >>> for sure.
> > >>>
> > >>>>
> > >>>> alias -- \
> > >>>> p='printf %s\\n ' \
> > >>>> assign='assign=$(( ' begin='$(( ' \
> > >>>>
> > >>>> for data in "1 + 2"
> > >>>> do
> > >>>> alias -- data="$d "
> > >>>> p begin data ))
> > >>>> done
> > >>>>
> > >>>> this works and results 3
> > >>>
> > >>> OK, let's go through it. I'll gloss over some non-essential details and
> > >>> simplify others. I'll skip over the bulk of the for loop parsing and
> > >>> just
> > >>> cover the simple command where alias expansion takes place.
> > >>>
> > >>> Since `p' is in a command position, it gets alias expanded to
> > >>> `printf %s\\n '. The lexical analysis restarts, the two words get
> > >>> scanned,
> > >>> and we start a simple command. The expansion ends with a space, so the
> > >>> next
> > >>> token (`begin') undergoes alias expansion, gets expanded to `$(( ', and
> > >>> the
> > >>> lex restarts. We read `$((' and know we're reading the start of a word
> > >>> that
> > >>> begins with an arithmetic expansion. We keep reading as if we are
> > >>> reading a
> > >>> double-quoted string, looking for `))', since that's what you do while
> > >>> reading an arithmetic expansion.
> > >>
> > >> so the alias expansion fails at the current command is no alias
> > >> anymore, so alias parsing rules dont apply anymore, .. no ... hmm .. ?
> > >> would make much sense then and i have nothing else to say..
> > >
> > > maybe ask about an shopt feature to enable straight alias expansion
> > > when the aliases are following ..
> >
> > How would that, whatever it is, help you here?
> >
> > --
> > ``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: Incorrect alias expansion within command substitution
it would make the whole work at alias level
alias (symbolic) 1=$(( 2=1+2 3=+ 4=1+2 5=))
1 2 3 4 5
works
[i wish]
On Sat, Feb 5, 2022 at 9:46 PM Chet Ramey wrote:
>
> On 2/5/22 3:44 PM, Alex fxmbsw7 Ratchev wrote:
> > On Sat, Feb 5, 2022 at 9:39 PM Alex fxmbsw7 Ratchev
> > wrote:
> >>
> >> On Sat, Feb 5, 2022 at 7:55 PM Chet Ramey wrote:
> >>>
> >>> On 2/4/22 6:17 PM, Alex fxmbsw7 Ratchev wrote:
> >>>> what about this viewing point
> >>>> aliases can start, $(('s, but not end... this is unlogic
> >>>
> >>> Well, I don't know about `unlogic' but there's an understanding deficit,
> >>> for sure.
> >>>
> >>>>
> >>>> alias -- \
> >>>> p='printf %s\\n ' \
> >>>> assign='assign=$(( ' begin='$(( ' \
> >>>>
> >>>> for data in "1 + 2"
> >>>> do
> >>>> alias -- data="$d "
> >>>> p begin data ))
> >>>> done
> >>>>
> >>>> this works and results 3
> >>>
> >>> OK, let's go through it. I'll gloss over some non-essential details and
> >>> simplify others. I'll skip over the bulk of the for loop parsing and just
> >>> cover the simple command where alias expansion takes place.
> >>>
> >>> Since `p' is in a command position, it gets alias expanded to
> >>> `printf %s\\n '. The lexical analysis restarts, the two words get scanned,
> >>> and we start a simple command. The expansion ends with a space, so the
> >>> next
> >>> token (`begin') undergoes alias expansion, gets expanded to `$(( ', and
> >>> the
> >>> lex restarts. We read `$((' and know we're reading the start of a word
> >>> that
> >>> begins with an arithmetic expansion. We keep reading as if we are reading
> >>> a
> >>> double-quoted string, looking for `))', since that's what you do while
> >>> reading an arithmetic expansion.
> >>
> >> so the alias expansion fails at the current command is no alias
> >> anymore, so alias parsing rules dont apply anymore, .. no ... hmm .. ?
> >> would make much sense then and i have nothing else to say..
> >
> > maybe ask about an shopt feature to enable straight alias expansion
> > when the aliases are following ..
>
> How would that, whatever it is, help you here?
>
> --
> ``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: Incorrect alias expansion within command substitution
On Sat, Feb 5, 2022 at 9:39 PM Alex fxmbsw7 Ratchev wrote:
>
> On Sat, Feb 5, 2022 at 7:55 PM Chet Ramey wrote:
> >
> > On 2/4/22 6:17 PM, Alex fxmbsw7 Ratchev wrote:
> > > what about this viewing point
> > > aliases can start, $(('s, but not end... this is unlogic
> >
> > Well, I don't know about `unlogic' but there's an understanding deficit,
> > for sure.
> >
> > >
> > > alias -- \
> > > p='printf %s\\n ' \
> > > assign='assign=$(( ' begin='$(( ' \
> > >
> > > for data in "1 + 2"
> > > do
> > > alias -- data="$d "
> > > p begin data ))
> > > done
> > >
> > > this works and results 3
> >
> > OK, let's go through it. I'll gloss over some non-essential details and
> > simplify others. I'll skip over the bulk of the for loop parsing and just
> > cover the simple command where alias expansion takes place.
> >
> > Since `p' is in a command position, it gets alias expanded to
> > `printf %s\\n '. The lexical analysis restarts, the two words get scanned,
> > and we start a simple command. The expansion ends with a space, so the next
> > token (`begin') undergoes alias expansion, gets expanded to `$(( ', and the
> > lex restarts. We read `$((' and know we're reading the start of a word that
> > begins with an arithmetic expansion. We keep reading as if we are reading a
> > double-quoted string, looking for `))', since that's what you do while
> > reading an arithmetic expansion.
>
> so the alias expansion fails at the current command is no alias
> anymore, so alias parsing rules dont apply anymore, .. no ... hmm .. ?
> would make much sense then and i have nothing else to say..
maybe ask about an shopt feature to enable straight alias expansion
when the aliases are following ..
cheers and peace
> btw the printf leet were examples about the other, not to work, not to
> say i tried to code so
>
> > There is no alias expansion because we are
> > not reading a new token and the contents of the arithmetic expansion are
> > treated like a double-quoted string, both disqualifying conditions. We find
> > those two characters, closing the arithmetic expansion, and go on looking
> > for the end of the word. We read a newline, which delimits the token, which
> > is the (shell grammar) WORD `$(( data ))'.
> >
> > After we finish parsing the for loop, we go back to execute it. We run
> > a useless `alias' command, then come to the simple command
> >
> > printf %s\\n $((data))
> >
> > (I removed the spaces from the arithmetic expansion to make it clear that
> > it's one word.)
> >
> > We begin to expand the words in this simple command. When we come to the
> > arithmetic expansion, we take the contents (`data') and run them through
> > the arithmetic evaluator. We get an identifier (`data'), assume it's a
> > shell variable, look up its value (`1 + 2', since that's how the for loop
> > set it) and evaluate that as an expression. It evaluates to 3, and the
> > string "3" becomes the result of the arithmetic expansion.
> >
> > We run
> >
> > printf %s\n 3
> >
> > and get `3' as output.
> >
> > Understand?
>
> yes, now, fail at no more alias so no alias expanded
>
> cheers, thank you much for your kind good effords
>
> > --
> > ``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: Incorrect alias expansion within command substitution
On Sat, Feb 5, 2022 at 7:55 PM Chet Ramey wrote:
>
> On 2/4/22 6:17 PM, Alex fxmbsw7 Ratchev wrote:
> > what about this viewing point
> > aliases can start, $(('s, but not end... this is unlogic
>
> Well, I don't know about `unlogic' but there's an understanding deficit,
> for sure.
>
> >
> > alias -- \
> > p='printf %s\\n ' \
> > assign='assign=$(( ' begin='$(( ' \
> >
> > for data in "1 + 2"
> > do
> > alias -- data="$d "
> > p begin data ))
> > done
> >
> > this works and results 3
>
> OK, let's go through it. I'll gloss over some non-essential details and
> simplify others. I'll skip over the bulk of the for loop parsing and just
> cover the simple command where alias expansion takes place.
>
> Since `p' is in a command position, it gets alias expanded to
> `printf %s\\n '. The lexical analysis restarts, the two words get scanned,
> and we start a simple command. The expansion ends with a space, so the next
> token (`begin') undergoes alias expansion, gets expanded to `$(( ', and the
> lex restarts. We read `$((' and know we're reading the start of a word that
> begins with an arithmetic expansion. We keep reading as if we are reading a
> double-quoted string, looking for `))', since that's what you do while
> reading an arithmetic expansion.
so the alias expansion fails at the current command is no alias
anymore, so alias parsing rules dont apply anymore, .. no ... hmm .. ?
would make much sense then and i have nothing else to say..
btw the printf leet were examples about the other, not to work, not to
say i tried to code so
> There is no alias expansion because we are
> not reading a new token and the contents of the arithmetic expansion are
> treated like a double-quoted string, both disqualifying conditions. We find
> those two characters, closing the arithmetic expansion, and go on looking
> for the end of the word. We read a newline, which delimits the token, which
> is the (shell grammar) WORD `$(( data ))'.
>
> After we finish parsing the for loop, we go back to execute it. We run
> a useless `alias' command, then come to the simple command
>
> printf %s\\n $((data))
>
> (I removed the spaces from the arithmetic expansion to make it clear that
> it's one word.)
>
> We begin to expand the words in this simple command. When we come to the
> arithmetic expansion, we take the contents (`data') and run them through
> the arithmetic evaluator. We get an identifier (`data'), assume it's a
> shell variable, look up its value (`1 + 2', since that's how the for loop
> set it) and evaluate that as an expression. It evaluates to 3, and the
> string "3" becomes the result of the arithmetic expansion.
>
> We run
>
> printf %s\n 3
>
> and get `3' as output.
>
> Understand?
yes, now, fail at no more alias so no alias expanded
cheers, thank you much for your kind good effords
> --
> ``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: Incorrect alias expansion within command substitution
it seems me here the data was used as var inside $(( not as alias
i tried d1 d2 d3 combination and didnt work
On Sat, Feb 5, 2022 at 12:17 AM Alex fxmbsw7 Ratchev wrote:
>
> what about this viewing point
> aliases can start, $(('s, but not end... this is unlogic
>
> alias -- \
> p='printf %s\\n ' \
> assign='assign=$(( ' begin='$(( ' \
>
> for data in "1 + 2"
> do
> alias -- data="$d "
> p begin data ))
> done
>
> this works and results 3
>
> its just, early bugs, unlogic :)
>
> On Sat, Feb 5, 2022 at 12:11 AM Alex fxmbsw7 Ratchev
> wrote:
> >
> >
> >
> > On Fri, Feb 4, 2022, 23:12 Chet Ramey wrote:
> >>
> >> On 2/4/22 2:56 PM, Alex fxmbsw7 Ratchev wrote:
> >>
> >> >>> by flat non lexical text parsing, excepts for quotes but then $(
> >> >>> logically
> >> >>> expands, excepts:
> >> >>> but imho the topic here is how far to expand shell stuff at this
> >> >>> position,
> >> >>> however factically its just needs to be a constant data separator
> >> >>
> >> >> Well, you'd certainly have something here if your shell did that. It
> >> >> wouldn't be a POSIX shell, though.
> >> >
> >> > it was my mind shell
> >> >
> >> > does it mean it wont ever get to be the regex /<<([^ \t\f\v\r\n;]+)
> >> >
> >> > that is, after << is parsed a read word till next space,
> >>
> >> That's just not how it works, and never has. There's no exception for the
> >> word that is the here-doc delimiter. It's a shell word like any other; the
> >> difference is in the expansions it undergoes.
> >>
> >>
> >> > no shell expansion
> >> > logic of separated functional structures in the topic of flat data is
> >> > overruling, you are overseeing
> >> >
> >> > for me <<$( e o f )
> >> > blabla
> >> > $( e o f )
> >> >
> >> > is pure early bug
> >>
> >> It's simply not the `flat data' you think it is or should be.
> >>
> >> (And that construct is certainly not something anyone should use, `early
> >> bug' or not.)
> >
> >
> > i see, :)
> > thanks and sorry
> >>
> >>
> >> --
> >> ``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: Incorrect alias expansion within command substitution
what about this viewing point
aliases can start, $(('s, but not end... this is unlogic
alias -- \
p='printf %s\\n ' \
assign='assign=$(( ' begin='$(( ' \
for data in "1 + 2"
do
alias -- data="$d "
p begin data ))
done
this works and results 3
its just, early bugs, unlogic :)
On Sat, Feb 5, 2022 at 12:11 AM Alex fxmbsw7 Ratchev wrote:
>
>
>
> On Fri, Feb 4, 2022, 23:12 Chet Ramey wrote:
>>
>> On 2/4/22 2:56 PM, Alex fxmbsw7 Ratchev wrote:
>>
>> >>> by flat non lexical text parsing, excepts for quotes but then $(
>> >>> logically
>> >>> expands, excepts:
>> >>> but imho the topic here is how far to expand shell stuff at this
>> >>> position,
>> >>> however factically its just needs to be a constant data separator
>> >>
>> >> Well, you'd certainly have something here if your shell did that. It
>> >> wouldn't be a POSIX shell, though.
>> >
>> > it was my mind shell
>> >
>> > does it mean it wont ever get to be the regex /<<([^ \t\f\v\r\n;]+)
>> >
>> > that is, after << is parsed a read word till next space,
>>
>> That's just not how it works, and never has. There's no exception for the
>> word that is the here-doc delimiter. It's a shell word like any other; the
>> difference is in the expansions it undergoes.
>>
>>
>> > no shell expansion
>> > logic of separated functional structures in the topic of flat data is
>> > overruling, you are overseeing
>> >
>> > for me <<$( e o f )
>> > blabla
>> > $( e o f )
>> >
>> > is pure early bug
>>
>> It's simply not the `flat data' you think it is or should be.
>>
>> (And that construct is certainly not something anyone should use, `early
>> bug' or not.)
>
>
> i see, :)
> thanks and sorry
>>
>>
>> --
>> ``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: Incorrect alias expansion within command substitution
On Fri, Feb 4, 2022, 23:12 Chet Ramey wrote: > On 2/4/22 2:56 PM, Alex fxmbsw7 Ratchev wrote: > > >>> by flat non lexical text parsing, excepts for quotes but then $( > logically > >>> expands, excepts: > >>> but imho the topic here is how far to expand shell stuff at this > position, > >>> however factically its just needs to be a constant data separator > >> > >> Well, you'd certainly have something here if your shell did that. It > >> wouldn't be a POSIX shell, though. > > > > it was my mind shell > > > > does it mean it wont ever get to be the regex /<<([^ \t\f\v\r\n;]+) > > > > that is, after << is parsed a read word till next space, > > That's just not how it works, and never has. There's no exception for the > word that is the here-doc delimiter. It's a shell word like any other; the > difference is in the expansions it undergoes. > > > > no shell expansion > > logic of separated functional structures in the topic of flat data is > > overruling, you are overseeing > > > > for me <<$( e o f ) > > blabla > > $( e o f ) > > > > is pure early bug > > It's simply not the `flat data' you think it is or should be. > > (And that construct is certainly not something anyone should use, `early > bug' or not.) > i see, :) thanks and sorry > > -- > ``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: Incorrect alias expansion within command substitution
On Fri, Feb 4, 2022 at 10:18 PM Robert Elz wrote:
>
> Date:Fri, 4 Feb 2022 21:06:11 +0100
> From: Alex fxmbsw7 Ratchev
> Message-ID:
>
>
>
> | now changing this to dynamic eof marker
>
> There is no such thing. Unlikely (*VERY* unlikely) there ever will be.
>
> | cat <<$( printf leet )
> | $( printf leet )
> | $( printf leet )
> | notice the two spaces in the middle to not match eof
>
> Yes, that is supposed to work, and "cat" should write a single
> line containing "leet". The end word is *never* expanded, not
> the copy of it after the << operator, and not the one that terminates
> the here doc data (the former gets quote removal, but there are none
> here to remove).
i guess thats not rendundant enough for bash, or yet too early
cause it doesnt interpret at runtime much yet, it just maps text or
chars to read until
also its a high security risk, how to say... to let $( and all << as
separator is all nonsense
> Since there are no quotes in the end word on the << operator, the
> here doc text is expanded (when used, not when read - though in this
> example it is used immediately when it is read, so that also makes no
> apparent difference - but giving examples where it does is easy).
> That includes expanding command substitutions inside the here doc
> text (which does not include the end word). The $( printf leet )
> produces "leet" on stdout, which replaces the command substitution
> text in the here doc, so cat reads (and outputs) the single line "leet".
>
> | thats valid code, cause eof is written twice ( the $( .. ) code )
>
> No idea what you mean there - but yes, the end word must be written
> twice, once after << and once after the here doc data. If you're
> counting the one that was inside the here doc (because it looks similar)
> then that's pure co-incidence, that one could be anything, and while altering
> that might change the input cat reads (and hence writes) it has no other
> impact on anything at all. You could even omit it entirely.
written twice.. to match eof matching, but why
if you start your << with $( printf leet ) or $( printf leet ) and
just wanna end with 'leet' .. .. .. you need command subst ( aka same
code ) to match instead of the resulting text ? hm
well there are many sides of coding i see
> | but
> |
> | cat <<$( printf end )
> | $( printf end )
> | # here it should already end the heredoc parser
>
> No it shouldn't. The 2nd line there doesn't have enough spaces,
> they're not the same.
i didnt continue the last line that matched the same command substitution
it was a try to example from a view of interpreting the text dynamically
still a bit unclear to me
>
> The end word (after <<) is parsed as a command substitution, to find its
> end, but is never expanded (the code in it is never executed) - all the
> parsing accomplishes in this case is to allow the correct ')' to be found
> so the command substitution text ends at the correct place - beyond that
> it is ignored.
what are you saying isnt clear to me
do you want $( to expand or not
i thought you wanted
> Perhaps a different example - I'm sure you know that in $(( )) you can
> embed an arithmetic expression, and if you try and do something like
>
> $(( data 2 ))
>
> you'll get a syntax error, because "data 2" is not a valid arithmetic
> expression.
you get this cause alias parsing is disabled, cause $(( is a command
an alias $(( would work
but bash doesnt handle the ending right yet
hint to chet: its just sad it results yet early in a code parse error
#!/usr/bin/env -S bash
shopt -s expand_aliases
alias -- \
p='printf %s\\n ' \
assign='assign=$(( ' begin='$(( ' end=')) ' \
sep=', ' \
plus=+\ minus=-\ div=/\ mul=\*\ \
for d in "1 + 2" "1 plus 2"
do
alias -- data="$d "
p begin data end
done
nevermind i realized its exactly the same and i understood why its erroring
alias.sh: line 14: unexpected EOF while looking for matching `)'
alias.sh: line 16: syntax error: unexpected end of file
cause bash doesnt parse aliases yet into pre parse state
yea i just wish it would, such as no code error for valid code
> But collecting the text of arithmetic is done by simply looking for the '))'
> that matches the '((' after the opening '$' (taking account of any other
> parentheses that might exist in the expression). The actual arithmetic isn't
> evaluated (or parsed) until it is to be expanded - it is simply a string.
>
> That means you can do (should be able to do, not all shells work properly)
>
> cat <<$(( any random trash *$ ^%%\ # you like - except for parentheses ))
factically, this
Re: Incorrect alias expansion within command substitution
On Fri, Feb 4, 2022 at 8:56 PM Alex fxmbsw7 Ratchev wrote:
>
> On Fri, Feb 4, 2022 at 8:28 PM Chet Ramey wrote:
> >
> > On 2/4/22 2:23 PM, Alex fxmbsw7 Ratchev wrote:
> >
> > > > imho the example above should have resulted in error ')'
> > > > it would execute cat a b ) with hello till $( then rather \n and a
> > > b )
> > > > again, useless
> > > > especially the $( wasnt even quoted
> > >
> > > What can this possibly mean? What semantic interpretation would lead
> > > you
> > > to the conclusion that you should stop reading the token after a `$('
> > > in
> > > this one specific case?
> > >
> > >
> > > by flat non lexical text parsing, excepts for quotes but then $( logically
> > > expands, excepts:
> > > but imho the topic here is how far to expand shell stuff at this position,
> > > however factically its just needs to be a constant data separator
> >
> > Well, you'd certainly have something here if your shell did that. It
> > wouldn't be a POSIX shell, though.
>
> it was my mind shell
>
> does it mean it wont ever get to be the regex /<<([^ \t\f\v\r\n;]+)
>
> that is, after << is parsed a read word till next space, no shell expansion
> logic of separated functional structures in the topic of flat data is
> overruling, you are overseeing
the data functional topic here would be alike 'data has to be parsed,
as simple as possible, till eof marker is reached'
now changing this to dynamic eof marker ( not like it would recognize
not dynamic already so ) beyond
would be easily nested ( in eval or so ) possible, but else invalid in
code parsing
cause eof of such would never maybe be reached
cause its a dynamical $( printf leet_code ) one
in runtime, when parser 'eof me till' ( read till this specific eof )
it would try to read and execute so no ? i dunno if bash does it
example
cat <<$( printf leet )
$( printf leet )
$( printf leet )
notice the two spaces in the middle to not match eof
or in quotes, in the mode that bash mostly interpretes data
thats valid code, cause eof is written twice ( the $( .. ) code )
but
cat <<$( printf end )
$( printf end )
# here it should already end the heredoc parser
but bash doesnt eval far enough
so you with dynamical eofs will be eof syntax error no matching heredoc end
you can avoid that by an eval wrapper btw
eo=eof
eval "cat <<$eo
$data
$eo"
maybe .. just thoughts
but atm who can say it made the perfect software , .. =)
greets and sorry for bad english
> for me <<$( e o f )
> blabla
> $( e o f )
>
> is pure early bug
>
> >
> > --
> > ``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: Incorrect alias expansion within command substitution
On Fri, Feb 4, 2022 at 8:28 PM Chet Ramey wrote:
>
> On 2/4/22 2:23 PM, Alex fxmbsw7 Ratchev wrote:
>
> > > imho the example above should have resulted in error ')'
> > > it would execute cat a b ) with hello till $( then rather \n and a b
> > )
> > > again, useless
> > > especially the $( wasnt even quoted
> >
> > What can this possibly mean? What semantic interpretation would lead you
> > to the conclusion that you should stop reading the token after a `$(' in
> > this one specific case?
> >
> >
> > by flat non lexical text parsing, excepts for quotes but then $( logically
> > expands, excepts:
> > but imho the topic here is how far to expand shell stuff at this position,
> > however factically its just needs to be a constant data separator
>
> Well, you'd certainly have something here if your shell did that. It
> wouldn't be a POSIX shell, though.
it was my mind shell
does it mean it wont ever get to be the regex /<<([^ \t\f\v\r\n;]+)
that is, after << is parsed a read word till next space, no shell expansion
logic of separated functional structures in the topic of flat data is
overruling, you are overseeing
for me <<$( e o f )
blabla
$( e o f )
is pure early bug
>
> --
> ``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: Incorrect alias expansion within command substitution
On Fri, Feb 4, 2022, 20:18 Chet Ramey wrote:
> On 2/3/22 9:46 PM, Alex fxmbsw7 Ratchev wrote:
>
> > The case I had in question with the question about $( a b ) was this
> > one...
> >
> > cat <<$( a b )
> > hello
> > $( a b )
> >
> >
> > i think you are mis understanding the differencies here between shell
> > expression parsing, and a rather data only part which applies here
> > that is, <<{word} is a word and is threated as flat text word, in
> further
> > eof recognition, applying advanced expressions here seems me like an
> early bug
>
> It is a WORD (in the POSIX grammar sense), and so recursive parsing and
> alias expansion are required as soon as you hit the `$('. It's what you
> do with the word once you have it that matters.
>
> > imho the example above should have resulted in error ')'
> > it would execute cat a b ) with hello till $( then rather \n and a b )
> > again, useless
> > especially the $( wasnt even quoted
>
> What can this possibly mean? What semantic interpretation would lead you
> to the conclusion that you should stop reading the token after a `$(' in
> this one specific case?
>
by flat non lexical text parsing, excepts for quotes but then $( logically
expands, excepts:
but imho the topic here is how far to expand shell stuff at this position,
however factically its just needs to be a constant data separator
so <<$( would match eof to be $(
simplified logic, i dunno about 'word' in shell grammar with expansion, but
imho for a data separator such eval actment is invalid
> chet didnt you say there were no bugs ? =)
>
> I didn't, but how is that relevant here?
>
excuse me :)
>
> --
> ``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: Incorrect alias expansion within command substitution
On Wed, Feb 2, 2022, 20:43 Robert Elz wrote:
> Date:Wed, 2 Feb 2022 11:38:30 -0500
> From:Chet Ramey
> Message-ID: <7c422cbb-bba8-0a57-a565-eeb115120...@case.edu>
>
>
> | > How accurately can you reconstitute? That is, can you maintain the
> | > difference between $(a b) and $( a b ) for example ? How about
> $(a b) ?
> |
> | Does it make a semantic difference?
>
> No, but that's not the point.
>
> | The only thing I can think of that
> | might mess it up is when you have something like
> |
> | alias l='(' r=')'
> | echo $(l 4+4 r)
|
> | and you intend, for whatever perverse reason, to have this parsed as an
> | arithmetic expansion. I'm not sure that's worth supporting.
>
> Supporting that would be wrong. Aliases are only expanded in the command
> work position (which includes the 'l' there but never the 'r', it would
> need
> a newline before it, but you could add that it wouldn't affect the
> interpretation as arithmetic). But to be the command word position for
> either of them, the $( must be a command substitution, that decision must
> already have been made, and once it is, it is... It cannot turn back into
> arithmetic because the l happens to become '(', leaving two (( chars
> together,
> tokenisation does not go back and re-examine chars that were already
> examined.
> The $( was already found, the next ( is a whole new token.
>
> That is, you should never save the alias expanded input as literal text,
> to be combined with anything else, and scanned again later. That's simply
> wrong, expand aliases, the right side can combine with what follows, as
> that hasn't been read yet (beyond it ending the token which turns out to
> be the alias) but there can never be a joining to the left.
>
> So, no, definitely not worth "supporting", that can never be arithmetic.
>
> The case I had in question with the question about $( a b ) was this
> one...
>
> cat <<$( a b )
> hello
> $( a b )
>
>
i think you are mis understanding the differencies here between shell
expression parsing, and a rather data only part which applies here
that is, <<{word} is a word and is threated as flat text word, in further
eof recognition, applying advanced expressions here seems me like an early
bug
imho the example above should have resulted in error ')'
it would execute cat a b ) with hello till $( then rather \n and a b )
again, useless
especially the $( wasnt even quoted
chet didnt you say there were no bugs ? =)
> which works in bash 5.1.16, but doesn't in 5.2-(December 16). In the
> latter the end line needs to be $(a b). The spaces are lost -
> reconstituting
> really doesn't work for this purpose. (nb: no aliases involved anywhere
> here).
>
> Reconstituting is fine for -x tracing, and other similar purposes, but
> not here where the exact literal text is needed.
>
> For what it is worth, ksh93 (the version I have anyway) doesn't even
> get started...
>
> ksh93 $ cat <<$( a b )
> /usr/pkg/bin/ksh93: syntax error at line 1: `< contained within command substitution
>
> And I hate to even imagine what state it got itself into to produce that
> diagnostic.
>
> yash and zsh get this example correct, along with released bash. Nothing
> else I tested does - everything other than bosh (everything includes the
> NetBSD sh) generates an error of some kind on the here doc redirect. Bosh
> generates one at the first extra newline after the apparent end delimiter
> (ie: given the above input, it doesn't complain, just sits there waiting
> for more - type a \n at it, and then it complains about a syntax error.
>
> | You need to be able to reconstruct the text of arbitrary commands for
> | `set -x'. It's a very short step from that to rebuilding a command
> | substitution.
>
> There are some things that -x typically does not show anything like
> as input (in bash, try a case statement for example). What appears
> is fine for -x output, but not even close for reconstitution.
>
> This one works in released bash, but not in 5.2-xxx (and no white space
> tricks with this one to mess things up --- and I also did not try to guess
> what the end delimiter might actually work, if anything):
>
> cat <<$(case $x in a) echo found A;; b) echo found B;& *) echo found $x ;;
> esac)
> hello
> $(case $x in a) echo found A;; b) echo found B;& *) echo found $x ;; esac)
>
> (Doesn't matter what 'x' is for this, the "command substitution" is never
> actually executed - all that is simply text.) yash cannot parse that one
> properly, only released bash and zsh get this right, ksh93 failed in a
> similar way to above, didn't bother testing any of the others, none will
> work.
>
> Bash's -x output doesn't include redirections either, so unsurprisingly
> this one doesn't work in 5.2-xxx
>
> cat <<$(cat hello
> $(cat
> It does in zsh, released bash, and perhaps surprisingly, ksh93 (nothing
> else).
> Our shell does include redirections in -x
Re: Incorrect alias expansion within command substitution
On Thu, Feb 3, 2022, 20:02 Chet Ramey wrote:
> On 2/2/22 1:30 PM, Robert Elz wrote:
> > Date:Wed, 2 Feb 2022 11:38:30 -0500
> > From:Chet Ramey
> > Message-ID: <7c422cbb-bba8-0a57-a565-eeb115120...@case.edu>
> >
> >
> >| > How accurately can you reconstitute? That is, can you maintain
> the
> >| > difference between $(a b) and $( a b ) for example ? How about
> $(a b) ?
> >|
> >| Does it make a semantic difference?
> >
> > No, but that's not the point.
>
> My argument is like yours -- is there a return on the investment of effort
> to make it worth doing, if the current state preserves semantics?
>
> It's clear that POSIX requires recursive parsing during which aliases are
> expanded. Changing the code to do that is worth the effort: it's my effort
> and I get to make that judgement.
>
> It's less clear that POSIX requires the exact original text, and it's just
> as clear that, let's say, implementations differ in this area.
>
>
> >
> >| The only thing I can think of that
> >| might mess it up is when you have something like
> >|
> >| alias l='(' r=')'
> >| echo $(l 4+4 r)
> >|
> >| and you intend, for whatever perverse reason, to have this parsed
> as an
> >| arithmetic expansion. I'm not sure that's worth supporting.
> >
> > Supporting that would be wrong.
>
> And that's why bash doesn't do it.
>
alias 0='echo ' 1='$(( ' 2=')) ' data=2+3' '
thats why this doesnt work, or what
0 1 data 2
>
im your example above you misknow that aliases are expanded as only commands
you specify in $( '(' as the command
you maybe meant like i tried $((
cause ( is no math expression
no idea why mine failed, bash bug
>
>
> > The case I had in question with the question about $( a b ) was this
> > one...
> >
> > cat <<$( a b )
> > hello
> > $( a b )
> >
> > which works in bash 5.1.16, but doesn't in 5.2-(December 16). In the
> > latter the end line needs to be $(a b). The spaces are lost -
> reconstituting
> > really doesn't work for this purpose. (nb: no aliases involved anywhere
> > here).
>
> Refer to my ROI comment above.
>
> > For what it is worth, ksh93 (the version I have anyway) doesn't even
> > get started...
> >
> > ksh93 $ cat <<$( a b )
> > /usr/pkg/bin/ksh93: syntax error at line 1: `< contained within command substitution
> >
> > And I hate to even imagine what state it got itself into to produce that
> > diagnostic.
>
> The only person reading this with a chance to know that answer is Martijn.
>
>
> >| You need to be able to reconstruct the text of arbitrary commands
> for
> >| `set -x'. It's a very short step from that to rebuilding a command
> >| substitution.
> >
> > There are some things that -x typically does not show anything like
> > as input (in bash, try a case statement for example). What appears
> > is fine for -x output, but not even close for reconstitution.
>
> OK. You need to be able to reconsistute text for `type' output. That
> includes everything, including redirections, because you need it to
> accurately reproduce shell functions.
>
> >
> > This one works in released bash, but not in 5.2-xxx (and no white space
> > tricks with this one to mess things up --- and I also did not try to
> guess
> > what the end delimiter might actually work, if anything):
> >
> > cat <<$(case $x in a) echo found A;; b) echo found B;& *) echo found $x
> ;; esac)
> > hello
> > $(case $x in a) echo found A;; b) echo found B;& *) echo found $x ;;
> esac)
>
> These examples are getting more and more hyperbolic. I'm comfortable with
> not supporting this use case.
>
>
> > cat <<$(cat > hello
> > $(cat
> It's not because the reconstituted text doesn't include redirections; the
> error message tells you that. And, in fact, this works:
>
> cat <<$(cat hello
> $(cat < /dev/null)
>
> though that's neither here nor there.
>
> > If you abandoned reconstituting, and simply saved the string, however
> > difficult that might be none of these issues would arise.
> >
> > It must be possible, the lexer is reading chars from somewhere, all it
> > needs to happen is to be told when to start saving, and when to stop).
>
> Of course it's possible. Is it worth the implementation effort?
>
> 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/
>
>
Re: Incorrect alias expansion within command substitution
btw u just need a two teee's there one l.int local int ome g.int for with -g and the setting for non g may not be a function On Thu, Feb 3, 2022, 22:28 L A Walsh wrote: > > > On 2022/02/03 11:02, Chet Ramey wrote: > > On 2/2/22 10:18 PM, Robert Elz wrote: > > > >> Date:Wed, 02 Feb 2022 17:18:08 -0800 > >> From:L A Walsh > >> Message-ID: <61fb2d50.7010...@tlinx.org> > >> > >>| My posix non-conformance issue has to do with bash not starting > with > >>| aliases enabled by default in all default invocations. > >> > >> If you're using aliases in scripts, then just stop doing that. > >> There's no need for it, it just makes your script harder to > >> follow. Simply expand any aliases you"d use interactively, > >> and you will no longer care about this. > >> > > > > There's no problem with using aliases in private scripts you write for > your > > own purposes. > Going against the POSIX standard in enabling aliases on startup would be no > problem if it was in your private shell for your own purposes... > > If you want to impose some personal style you find easier to > > read, so be it. Even advocating for that style is ok, if you don't > expect to be taken seriously unless you provide evidence of concrete > benefits. > > > --- > If you want to impose your personal bash startup options on the general > shell used by default on most systems, so be it. But please don't > expect to be taken seriously when you arbitrarily disable default > posix options at startup unless you provide evidence of concrete benefits. > > In a similar way when one does a 'read var < fn' and you decide to add > a warning if 'fn' ended with a binary '0', that would be fine if it only > affected > you, but you added the warning claiming it was solving some problem > complained about > by some users. When I asked for concrete evidence of benefits or the > large number > of users askign for that, I was attacked. Yet you ask to be taken > seriously when > you implement changes that no one had asked for on bug-bash. > > > The issue is expecting others to understand or be able to help with > scripts > > written in that style, or expect them to invest time learning it. That's > > just not reasonable. > > If you are claiming it takes them significant time to learn what: > > > shopt -s expand_aliases; alias int='declare -i ' > means, How do you expect them to learn shell basics from 'man bash'? > > More than one person has commented the level of clarity of bash > documentation. > > I've have yet to find someone who doesn't understand what > 'int var=1' means. > > Documentation that has confused more than one poster on this list > is hardly a standard one should aspire to. It is, at best, 'terse'. > > versus my alias usage that attempts to improve clarity. > > > > >
Re: Incorrect alias expansion within command substitution
On Thu, Feb 3, 2022, 22:14 Alex fxmbsw7 Ratchev wrote:
>
>
> On Thu, Feb 3, 2022, 20:02 Chet Ramey wrote:
>
>> On 2/2/22 1:30 PM, Robert Elz wrote:
>> > Date:Wed, 2 Feb 2022 11:38:30 -0500
>> > From:Chet Ramey
>> > Message-ID: <7c422cbb-bba8-0a57-a565-eeb115120...@case.edu>
>> >
>> >
>> >| > How accurately can you reconstitute? That is, can you maintain
>> the
>> >| > difference between $(a b) and $( a b ) for example ? How about
>> $(a b) ?
>> >|
>> >| Does it make a semantic difference?
>> >
>> > No, but that's not the point.
>>
>> My argument is like yours -- is there a return on the investment of effort
>> to make it worth doing, if the current state preserves semantics?
>>
>> It's clear that POSIX requires recursive parsing during which aliases are
>> expanded. Changing the code to do that is worth the effort: it's my effort
>> and I get to make that judgement.
>>
>> It's less clear that POSIX requires the exact original text, and it's just
>> as clear that, let's say, implementations differ in this area.
>>
>>
>> >
>> >| The only thing I can think of that
>> >| might mess it up is when you have something like
>> >|
>> >| alias l='(' r=')'
>> >| echo $(l 4+4 r)
>> >|
>> >| and you intend, for whatever perverse reason, to have this parsed
>> as an
>> >| arithmetic expansion. I'm not sure that's worth supporting.
>> >
>> > Supporting that would be wrong.
>>
>> And that's why bash doesn't do it.
>>
>
> alias 0='echo ' 1='$(( ' 2=')) ' data=2+3' '
>
> thats why this doesnt work, or what
>
> 0 1 data 2
> >
>
the eval variant is worse
0 1 data 2
bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file
>
> im your example above you misknow that aliases are expanded as only
> commands
> you specify in $( '(' as the command
> you maybe meant like i tried $((
> cause ( is no math expression
> no idea why mine failed, bash bug
>
>>
>>
>> > The case I had in question with the question about $( a b ) was this
>> > one...
>> >
>> > cat <<$( a b )
>> > hello
>> > $( a b )
>> >
>> > which works in bash 5.1.16, but doesn't in 5.2-(December 16). In the
>> > latter the end line needs to be $(a b). The spaces are lost -
>> reconstituting
>> > really doesn't work for this purpose. (nb: no aliases involved
>> anywhere
>> > here).
>>
>> Refer to my ROI comment above.
>>
>> > For what it is worth, ksh93 (the version I have anyway) doesn't even
>> > get started...
>> >
>> > ksh93 $ cat <<$( a b )
>> > /usr/pkg/bin/ksh93: syntax error at line 1: `<> contained within command substitution
>> >
>> > And I hate to even imagine what state it got itself into to produce that
>> > diagnostic.
>>
>> The only person reading this with a chance to know that answer is Martijn.
>>
>>
>> >| You need to be able to reconstruct the text of arbitrary commands
>> for
>> >| `set -x'. It's a very short step from that to rebuilding a command
>> >| substitution.
>> >
>> > There are some things that -x typically does not show anything like
>> > as input (in bash, try a case statement for example). What appears
>> > is fine for -x output, but not even close for reconstitution.
>>
>> OK. You need to be able to reconsistute text for `type' output. That
>> includes everything, including redirections, because you need it to
>> accurately reproduce shell functions.
>>
>> >
>> > This one works in released bash, but not in 5.2-xxx (and no white space
>> > tricks with this one to mess things up --- and I also did not try to
>> guess
>> > what the end delimiter might actually work, if anything):
>> >
>> > cat <<$(case $x in a) echo found A;; b) echo found B;& *) echo found $x
>> ;; esac)
>> > hello
>> > $(case $x in a) echo found A;; b) echo found B;& *) echo found $x ;;
>> esac)
>>
>> These examples are getting more and more hyperbolic. I'm comfortable with
>> not supporting this use case.
>>
>>
>> > cat <<$(cat> > hello
>> > $(cat>
>> It's not because the reconstituted text doesn't include redirections; the
>> error message tells you that. And, in fact, this works:
>>
>> cat <<$(cat> hello
>> $(cat < /dev/null)
>>
>> though that's neither here nor there.
>>
>> > If you abandoned reconstituting, and simply saved the string, however
>> > difficult that might be none of these issues would arise.
>> >
>> > It must be possible, the lexer is reading chars from somewhere, all it
>> > needs to happen is to be told when to start saving, and when to stop).
>>
>> Of course it's possible. Is it worth the implementation effort?
>>
>> 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/
>>
>>
Re: Incorrect alias expansion within command substitution
On Thu, Feb 3, 2022, 18:16 Dennis Williamson wrote: > > > On Thu, Feb 3, 2022, 11:14 AM Alex fxmbsw7 Ratchev > wrote: > >> aliases are the way not to write duplicate code >> >> > > > No, functions are. > im your dreams.. >
Re: Incorrect alias expansion within command substitution
aliases are the way not to write duplicate code On Thu, Feb 3, 2022, 18:06 L A Walsh wrote: > > > On 2022/02/03 07:02, Alex fxmbsw7 Ratchev wrote: > > > > > > On Thu, Feb 3, 2022, 04:20 Robert Elz > <mailto:k...@munnari.oz.au>> wrote: > > > > Date:Wed, 02 Feb 2022 17:18:08 -0800 > > From:L A Walsh mailto:b...@tlinx.org>> > > Message-ID: <61fb2d50.7010...@tlinx.org > > <mailto:61fb2d50.7010...@tlinx.org>> > > > > | My posix non-conformance issue has to do with bash not > > starting with > > | aliases enabled by default in all default invocations. > > > > If you're using aliases in scripts, then just stop doing that. > > > > Uh, No. > > > > u're tralla > > > > There's no need for it, it just makes your script harder to > > follow. > > > --- > I write scripts for myself. aliases make scriptes easier to create > modify and maintain. You can type 'declare -i x=1', I prefer 'int x=1' > I find 'declare -xxyz' harder to write, read and parse than 'my', > 'array' 'map' > > We aren't talking 100 aliases, but these: > alias my='declare ' int='my -i ' array='my -a ' map='my -A ' > > are used in nearly all my scripts. > > I use functions frequently I start off many of my scripts: > nalias include >& /dev/null > if [[ $(type -t include) != function ]]; then source ~/bin/include; fi > include stdalias > > Even though I have an stdalias.shh file, I rarely use the aliases in it > -- except > for the ones listed above. It depends on the script, but having aliases > matching types can help in more complex scripts. I can define something > with an alias, then check if a parameter matches its 'type'. my > Types.shh include file even > includes a builtin-test suite: > > Types.shh > Types v0.2 include file. Usage (in a script): > > include Types > > Cmdline options: > -h for this help > -t for self-test > > > Types.shh -t > test01: Define & Identify Basic Types: PASS > test02: define w/aliases+combos+identify: ... > 0. type(myarray)=array : PASS > 1. type(mymap)=map : PASS > 2. type(myint)=int : PASS > 3. type(int_array)=array Int: PASS > 4. type(int_map)=map Int: PASS > 5. type(exp_int_array)=array Int Export : PASS > 6. type(exp_int_map)=map Int Export : PASS > 7. type(low_array)=array Lower : PASS > 8. type(up_array)=array Upper : PASS > 9. type(exp_int_const)=int Const Export : PASS > > --- > The above routines break down type-defining aliases and > I can check that parameters passed to a subroutine are of the right type. > like: > if I had passed something declared with > alias 'int_map' to a function, I can test if it > is a 'map' (hash) with keys that point to integers. > > For dual types (like declare -al), I can use > array Lower foo=(...) > > > > Simply expand any aliases you"d use interactively, > > and you will no longer care about this. > > > --- > Except every time I type or read them, which is sorta the point. > > There is no way you can tell me that: > declare var='v' > declare -i ivar=1 > > are more clear than: > > my var='v' > int ivar=1 > >
Re: Incorrect alias expansion within command substitution
On Thu, Feb 3, 2022, 04:20 Robert Elz wrote: > Date:Wed, 02 Feb 2022 17:18:08 -0800 > From:L A Walsh > Message-ID: <61fb2d50.7010...@tlinx.org> > > | My posix non-conformance issue has to do with bash not starting with > | aliases enabled by default in all default invocations. > > If you're using aliases in scripts, then just stop doing that. > u're tralla There's no need for it, it just makes your script harder to > follow. Simply expand any aliases you"d use interactively, > and you will no longer care about this. > > aliases can be uaeful interactively, so you need to type less > (though generally functions work better and are more flexible) > but there's no excuse for that in a script. > > It's just the same with variable names - interactively I use > names like a b f ... - in a script I am much more likely to > use much more descriptive names (most good editors have a form > of macro expansion, where you get to just type a short word > and the editor expands that to a longer form - use that.) > > Most people who use aliases in scripts are simply trying to > show how clever they are, and like almost everyone who > attempts that, the result is usually the exact opposite. > > Just don't. > > kre > >
Re: Incorrect alias expansion within command substitution
i see only two solutions as an option one option does expand aliases inside safe out of the tree the other more eval ing On Thu, Feb 3, 2022, 02:27 L A Walsh wrote: > > > On 2022/02/02 08:50, Chet Ramey wrote: > > On 2/2/22 8:25 AM, L A Walsh wrote: > > > > > >> I.e. My bash is posix compliant by default w/r/t aliases: > >> > > > > It's not, and that's how this whole issue got started. You're running > > bash-4.4. POSIX requires the following to work: > > > > alias switch=case > > echo $(switch foo in foo) echo ok 2;; esac ) > > > > and it simply doesn't, whether you run in posix mode or not. > > > - > You are right in that I was entirely in left field. However w/r/t starting > with aliases being enabled by default when bash starts (interactive or > not), > I would prefer bash follow posix rules. > i prefer always bash extras over outdated incomplete stuff specs > While I compile my bash to follow posix rules, I can't quite write my > general scripts to expect that as bash at the trunc level > > I missed the original problem being talked about here. > > My posix non-conformance issue has to do with bash not starting with > aliases enabled by default in all default invocations. > > While BASH_ALIASES is inherited I can't specify a set of aliases that I can > expect to just 'work' when bash starts. > namespaces would do > > For that matter I can't expect my own maps (arrays with non-integer or > integer > to work in child processes. > i suggest an array exporting too, maybe with memory compression prolly not e > > I've tried to suggest various improvements over the years, and don't > understand the resistance of all the suggestion. > :/ > > I will admit that my focus is utility and usability rather than > security, ever since > the attack on bash function injections, but would have suggested using a > shared memory file owned by root to hold a key (checksum key) of > functions and secured variables. Perhaps not ideal, but, I believe > workable. > > Unfortunately, all of my ideas/works after last Thanksgiving have > suffered from a > decrease in mental function due to a nasty stroke that affected my visual > cortext -- affecting both eyes and image processing. Since I have been > highly > visually oriented, many of my memories, and ability to visualize my code > and even > see or read a line at a time are impaired, requiring me to read > word-by-word which > horribly slows down reading and virtually eliminates ability to skim > text -- the result being I often miss entire phrases, even sections. > Apparently from cat scan and MRI's that stroke as only one of the worse > was only 1 of several picked up > by the dianostics. > > > > So if it looks like I missed something -- I probably did. I also > sometimes have gaps > in a logical chain of though, because I thought it, but missed putting > it into words. > > So most sorry for missing key key points in arguments, as well as > missing under- standing, what to you are obvious points of joining logic. > > I will try to continue my to increase due-diligence, but will most > assuredly fail. > > My apologies. > Ms. Linda Walsh > (aka Astara) > (at) tlinx.org > > > > > Sadly this gives some rampant examples to point out my logical flaws and > my missing basic. points in a discussion. > > I apoligize in advance for my many > >
Re: Incorrect alias expansion within command substitution
On Wed, Feb 2, 2022, 21:59 Chet Ramey wrote: > On 2/2/22 1:40 PM, Martijn Dekker wrote: > > Op 01-02-22 om 15:23 schreef Chet Ramey: > >> Historically, bash (and ksh93) has favored the former. Just about all > the > >> other shells claiming some sort of POSIX conformance favor the latter > (all > >> the ash-based shells, yash, mksh). > >> > >> What are your plans here? > > > > I've no current plans. Any remotely plausible use of aliases is not going > > to be affected either way. I've done some pretty innovative stuff in > > modernish that involves aliases and that too would be unaffected. In my > > view, this difference is relevant to standards and regression test > writers > > and probably no one else. > > I agree; most current scripts will continue to run just fine. > > > Having said that, I've never understood why ksh stores command > > substitutions as unparsed source code (including comments and all) in the > > parse tree and only parses that at execution time -- including in dot > > scripts (which are otherwise parsed in their entirety before execution) > and > > shcomp bytecode output. That seems bizarre. It doesn't do that for > regular > > subshells in parentheses or for process substitutions. > > Probably because the paren commands are never parts of words and it makes > no sense to join a process substitution to another word. > > But command substitutions are parts of words (granted, most of the time the > complete word) so it's simpler to retain the text, parse it again to find > the closing `)' during expansion, and perform the command substitution > than to carry around an arbitrary number of parse trees along with the > word, including where each should start and end. It's probably more > bookkeeping than Korn wanted to do, though Ken Almquist managed it. > you just need two parts an expander, i guess a language parser and the alias expansion is like text expansion second part is again language interpret but then execute > > 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/ > >
Re: How to display parameters in a function backtrace?
my fault misunderstanding then too, sorry too cheers On Wed, Feb 2, 2022, 15:52 L A Walsh wrote: > > > On 2022/02/02 06:43, Alex fxmbsw7 Ratchev wrote: > > i had gdb new version > --- > This is about looking at a backtrace of shell functions in shell > > gdb may show a backtrace of shell functions, but gdb isn't > a shell debugger, but one for the source code of bash. > > If you look at my backtrace function -- it shows a backtrace of > shell functions, not a backtrace of bash itself. > > In that regard, I'm asking how to look at the parameters to a function > written in shell (not parameters to the 'c' functions inside the bash > source. > > Sorry if this is/was confusing. > > > >
Re: How to display parameters in a function backtrace?
the attached text is how it looks like since newly
On Wed, Feb 2, 2022 at 3:35 PM L A Walsh wrote:
>
> I was trying to find parameters to a function that gave an error, so
> I 'turned on' (included my backtracing routine), which showed:
>
> ./24bc: line 46: printf: `txt=\nRed,': not a valid identifier
> STOPPING execution @ "printf ${_:+-v $_} '\x1b[48;2;%s;%s;%sm' $1 $2 $3"
> in "setBgColor()" at ./24bc #46
> called in setBackBlack() at ./24bc #56
> called in title() at ./24bc #74
> called in main() at ./24bc #81
>
>
> I was all, 'rats, its not showing the params', I wondered why and looked
> at the code,
> and realized that while I can backtrace function, source line+file, I didn't
> know how to display the params that were used when the function was called.
>
> Is there, or maybe 'can there', be a BASH var like
> FUNCPARMS[1]="(P1 P2 P3)"
>
> Of course it would be handy if bash could parse this w/o using an
> intermediate var:
>
> echo "${${FUNCPARMS[@]}[1]}" =>
># (tmp=${FUNCPARMS[@]} tmp=(P1 P2 P3) )
># echo "${tmp[1]}"
> P1
>
> ---
> But even without the enhanced parsing output, it would still
> be useful if bash had & filled in the param vars.
>
> FUNCPARMS would parallel 'FUNCNAME', i.e.
> FUNCPARMS[1] would hold the quoted array "()" PARMS for FUNCNAME[1].
>
> FWIW, my primitive backtrace function (source or "include") follows:
>
>
> #!/bin/bash -u
>
> shopt -s expand_aliases
> alias my='declare ' int='my -i '
>
> backtrace () {
> trap ERR
> int level=0
> mycmd fn src ln
> int iter=0
> while {
> cmd=$BASH_COMMAND; fn=${FUNCNAME[level+1]:-}
> src=${BASH_SOURCE[level+1]:-} ln=${BASH_LINENO[level]:-}
> }; do
> [[ $fn && $src && $ln ]] && {
> if ((iter++==0)); then
> printf 'STOPPING execution @ "%s" in "%s()" at %s #%s\n' "$cmd"
> "$fn" "$src" "$ln"
> else
> printf ' called in %s() at %s #%s\n' "$fn" "$src" "$ln"
> fi
> level+=1
> continue;
> }
> exit 1
> done
> }
> set -o errtrace
> trap backtrace ERR
> trap backtrace QUIT
> set -E
>
>
>
gdb /bin/bash
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Re: How to display parameters in a function backtrace?
i had gdb new version and then it all displayed already all params to funcs
and stuff
(once seen)
On Wed, Feb 2, 2022, 15:35 L A Walsh wrote:
> I was trying to find parameters to a function that gave an error, so
> I 'turned on' (included my backtracing routine), which showed:
>
> ./24bc: line 46: printf: `txt=\nRed,': not a valid identifier
> STOPPING execution @ "printf ${_:+-v $_} '\x1b[48;2;%s;%s;%sm' $1 $2 $3"
> in "setBgColor()" at ./24bc #46
> called in setBackBlack() at ./24bc #56
> called in title() at ./24bc #74
> called in main() at ./24bc #81
>
>
> I was all, 'rats, its not showing the params', I wondered why and looked
> at the code,
> and realized that while I can backtrace function, source line+file, I
> didn't
> know how to display the params that were used when the function was called.
>
> Is there, or maybe 'can there', be a BASH var like
> FUNCPARMS[1]="(P1 P2 P3)"
>
> Of course it would be handy if bash could parse this w/o using an
> intermediate var:
>
> echo "${${FUNCPARMS[@]}[1]}" =>
># (tmp=${FUNCPARMS[@]} tmp=(P1 P2 P3) )
># echo "${tmp[1]}"
> P1
>
> ---
> But even without the enhanced parsing output, it would still
> be useful if bash had & filled in the param vars.
>
> FUNCPARMS would parallel 'FUNCNAME', i.e.
> FUNCPARMS[1] would hold the quoted array "()" PARMS for FUNCNAME[1].
>
> FWIW, my primitive backtrace function (source or "include") follows:
>
>
> #!/bin/bash -u
>
> shopt -s expand_aliases
> alias my='declare ' int='my -i '
>
> backtrace () {
> trap ERR
> int level=0
> mycmd fn src ln
> int iter=0
> while {
> cmd=$BASH_COMMAND; fn=${FUNCNAME[level+1]:-}
> src=${BASH_SOURCE[level+1]:-} ln=${BASH_LINENO[level]:-}
> }; do
> [[ $fn && $src && $ln ]] && {
> if ((iter++==0)); then
> printf 'STOPPING execution @ "%s" in "%s()" at %s #%s\n' "$cmd"
> "$fn" "$src" "$ln"
> else
> printf ' called in %s() at %s #%s\n' "$fn" "$src" "$ln"
> fi
> level+=1
> continue;
> }
> exit 1
> done
> }
> set -o errtrace
> trap backtrace ERR
> trap backtrace QUIT
> set -E
>
>
>
>
Re: Incorrect alias expansion within command substitution
ive had many inconsistency with bash this regarding exoerienced On Wed, Feb 2, 2022, 15:00 L A Walsh wrote: > On 2022/01/31 20:40, Martijn Dekker wrote: > > On the latest code from the devel branch: > > GNU bash, versie 5.2.0(35)-alpha (x86_64-apple-darwin18.7.0) > > > > Reproducer script: > > > > shopt -s expand_aliases > > alias let='let --' > > set -x > > let '1 == 1' > > : $(let '1 == 1') > > > > Output: > > > > + let -- '1 == 1' > > ++ let -- -- '1 == 1' > > foo: line 5: let: --: syntax error: operand expected (error token is "-") > > + : > > > > The alias is incorrectly expanded in the command substitution, > > duplicating the '--' argument and causing a syntax error. > > > > I can't say for sure, but it would be interesting if anyone else > has this result in a bash with aliases on by default: > > I.e. My bash is posix compliant by default w/r/t aliases: > > env -i /bin/bash --noprofile --norc > bash-4.4$ shopt -p expand_aliases > shopt -s expand_aliases > > and it doesn't show the above error: > > bash-4.4$ alias let='let --' > bash-4.4$ set -x > bash-4.4$ let '1 == 1' > + let -- '1 == 1' > bash-4.4$ : $(let '1 == 1') > ++ let -- '1 == 1' > + : > > It may not be the case, but to me, looked like the alias for 'let' had > been disabled > in the $() subshell as per standard bash behavior of disabling aliases > on startup. > > I.e. if you configure bash to be posix compliant w/r/t aliases on > shell startup, this seems to fix the above problem. > > > > > >
Re: Incorrect alias expansion within command substitution
On Tue, Feb 1, 2022, 19:25 Alex fxmbsw7 Ratchev wrote:
> you'd expand an alias if seen and then reinterpret the whats gotten also
> to ( possible ) current cmdline before alias
>
as with multiple heredocs in complex cmds
{
cmd "$( < /dev/fd/4 )" "$( < /dev/fd/3 )"
} 4<
> its hard to limit this to one cmd per chunk only
>
> you, 1. expand alias 2. it expanded to multiple complex cmds 3. bash
> parses the resulting text and does its per cmd recieved works
>
> On Tue, Feb 1, 2022, 19:22 Alex fxmbsw7 Ratchev wrote:
>
>>
>>
>> On Tue, Feb 1, 2022, 19:16 Alex fxmbsw7 Ratchev
>> wrote:
>>
>>>
>>>
>>> On Tue, Feb 1, 2022, 19:11 Chet Ramey wrote:
>>>
>>>> On 2/1/22 10:23 AM, Chet Ramey wrote:
>>>>
>>>> > If you defer alias expansion until execution, you lose the (posix-
>>>> > encouraged but officially unspecified according to the approved
>>>> > interpretation of issue 1342) ability to have aliases affect command
>>>> > parsing in the command substitution:
>>>>
>>>> Well, I went back and read the entire interpretation. The part that's
>>>> not
>>>> specified is whether an alias expansion provides the closing `)', but
>>>> alias
>>>> expansion has to be performed while parsing the contents of the command
>>>> substitution:
>>>>
>>>> "existing aliases are required to be expanded when the shell parses the
>>>> input that follows the "$(" in order to find the terminating ')'"
>>>>
>>>
>>> i see here only possible ) closing parsing, not doing so results in a
>>> mess
>>>
>>
>> if, there is a closing loose ) in the alias, i assume its for usage there
>> non legit cases are the invalid coded ones ( the 'wouldnt work anyway
>> cause wrong know )
>>
>>>
>>> for me, aliases as im bash ive experienced as text inplace replacements,
>>> flat text, then the cmdline parsing is done, so closing ) if easily
>>> specified by user yes works, else broken incomplete ( wrong pathed ) aliases
>>>
>>>>
>>>> and (in the same interpretation):
>>>>
>>>> "Historically some shells used simple parenthesis counting to find the
>>>> terminating ')' and therefore did not account for aliases. However, such
>>>> shells never conformed to POSIX, which has always required recursive
>>>> parsing (see XCU 2.3 item 5)."
>>>>
>>>> So this seems like behavior that should be conditional on posix mode to
>>>> preserve backwards compatibility.
>>>>
>>>> --
>>>> ``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: Incorrect alias expansion within command substitution
On Tue, Feb 1, 2022, 19:16 Alex fxmbsw7 Ratchev wrote:
>
>
> On Tue, Feb 1, 2022, 19:11 Chet Ramey wrote:
>
>> On 2/1/22 10:23 AM, Chet Ramey wrote:
>>
>> > If you defer alias expansion until execution, you lose the (posix-
>> > encouraged but officially unspecified according to the approved
>> > interpretation of issue 1342) ability to have aliases affect command
>> > parsing in the command substitution:
>>
>> Well, I went back and read the entire interpretation. The part that's not
>> specified is whether an alias expansion provides the closing `)', but
>> alias
>> expansion has to be performed while parsing the contents of the command
>> substitution:
>>
>> "existing aliases are required to be expanded when the shell parses the
>> input that follows the "$(" in order to find the terminating ')'"
>>
>
> i see here only possible ) closing parsing, not doing so results in a mess
>
if, there is a closing loose ) in the alias, i assume its for usage there
non legit cases are the invalid coded ones ( the 'wouldnt work anyway cause
wrong know )
>
> for me, aliases as im bash ive experienced as text inplace replacements,
> flat text, then the cmdline parsing is done, so closing ) if easily
> specified by user yes works, else broken incomplete ( wrong pathed ) aliases
>
>>
>> and (in the same interpretation):
>>
>> "Historically some shells used simple parenthesis counting to find the
>> terminating ')' and therefore did not account for aliases. However, such
>> shells never conformed to POSIX, which has always required recursive
>> parsing (see XCU 2.3 item 5)."
>>
>> So this seems like behavior that should be conditional on posix mode to
>> preserve backwards compatibility.
>>
>> --
>> ``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: Incorrect alias expansion within command substitution
On Tue, Feb 1, 2022, 19:11 Chet Ramey wrote:
> On 2/1/22 10:23 AM, Chet Ramey wrote:
>
> > If you defer alias expansion until execution, you lose the (posix-
> > encouraged but officially unspecified according to the approved
> > interpretation of issue 1342) ability to have aliases affect command
> > parsing in the command substitution:
>
> Well, I went back and read the entire interpretation. The part that's not
> specified is whether an alias expansion provides the closing `)', but alias
> expansion has to be performed while parsing the contents of the command
> substitution:
>
> "existing aliases are required to be expanded when the shell parses the
> input that follows the "$(" in order to find the terminating ')'"
>
i see here only possible ) closing parsing, not doing so results in a mess
for me, aliases as im bash ive experienced as text inplace replacements,
flat text, then the cmdline parsing is done, so closing ) if easily
specified by user yes works, else broken incomplete ( wrong pathed ) aliases
>
> and (in the same interpretation):
>
> "Historically some shells used simple parenthesis counting to find the
> terminating ')' and therefore did not account for aliases. However, such
> shells never conformed to POSIX, which has always required recursive
> parsing (see XCU 2.3 item 5)."
>
> So this seems like behavior that should be conditional on posix mode to
> preserve backwards compatibility.
>
> --
> ``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: Incorrect alias expansion within command substitution
you'd expand an alias if seen and then reinterpret the whats gotten also to
( possible ) current cmdline before alias
its hard to limit this to one cmd per chunk only
you, 1. expand alias 2. it expanded to multiple complex cmds 3. bash parses
the resulting text and does its per cmd recieved works
On Tue, Feb 1, 2022, 19:22 Alex fxmbsw7 Ratchev wrote:
>
>
> On Tue, Feb 1, 2022, 19:16 Alex fxmbsw7 Ratchev wrote:
>
>>
>>
>> On Tue, Feb 1, 2022, 19:11 Chet Ramey wrote:
>>
>>> On 2/1/22 10:23 AM, Chet Ramey wrote:
>>>
>>> > If you defer alias expansion until execution, you lose the (posix-
>>> > encouraged but officially unspecified according to the approved
>>> > interpretation of issue 1342) ability to have aliases affect command
>>> > parsing in the command substitution:
>>>
>>> Well, I went back and read the entire interpretation. The part that's not
>>> specified is whether an alias expansion provides the closing `)', but
>>> alias
>>> expansion has to be performed while parsing the contents of the command
>>> substitution:
>>>
>>> "existing aliases are required to be expanded when the shell parses the
>>> input that follows the "$(" in order to find the terminating ')'"
>>>
>>
>> i see here only possible ) closing parsing, not doing so results in a mess
>>
>
> if, there is a closing loose ) in the alias, i assume its for usage there
> non legit cases are the invalid coded ones ( the 'wouldnt work anyway
> cause wrong know )
>
>>
>> for me, aliases as im bash ive experienced as text inplace replacements,
>> flat text, then the cmdline parsing is done, so closing ) if easily
>> specified by user yes works, else broken incomplete ( wrong pathed ) aliases
>>
>>>
>>> and (in the same interpretation):
>>>
>>> "Historically some shells used simple parenthesis counting to find the
>>> terminating ')' and therefore did not account for aliases. However, such
>>> shells never conformed to POSIX, which has always required recursive
>>> parsing (see XCU 2.3 item 5)."
>>>
>>> So this seems like behavior that should be conditional on posix mode to
>>> preserve backwards compatibility.
>>>
>>> --
>>> ``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: Bash not escaping escape sequences in directory names
maybe sub'ing them away, or making it print \\e instead \e On Fri, Jan 21, 2022, 09:24 Lawrence Velázquez wrote: > On Fri, Jan 21, 2022, at 12:22 AM, L A Walsh wrote: > > On 2022/01/18 22:31, Alex fxmbsw7 Ratchev wrote > >>> Fix: > >>> Haven't looked deeply into the bash internals but sanitizing the > directory > >>> name (along with other user-controlled substitutions in the prompt) > should > >>> work. > >>> > > Sanitizing? What's that? > > Especially in a way that won't break existing legal usages? > > Curious what "existing legal usages" there are for allowing a change > of working directory to result in arbitrary escape sequences being > sent to your terminal. > > -- > vq > >
Re: Bash not escaping escape sequences in directory names
i vote for a more generous escape en/disable option On Fri, Jan 21, 2022, 06:23 L A Walsh wrote: > On 2022/01/18 22:31, Alex fxmbsw7 Ratchev wrote > >> Fix: > >> Haven't looked deeply into the bash internals but sanitizing the > directory > >> name (along with other user-controlled substitutions in the prompt) > should > >> work. > >> > Sanitizing? What's that? > Especially in a way that won't break existing legal usages? > > >
Re: devel: Questions about quoting in the new replacement ${var/pat/&}
i still vote for back referenceable groups
yes im no .c coder wush bye idea
On Thu, Jan 20, 2022, 02:48 Koichi Murase wrote:
> 2022年1月20日(木) 9:39 Chet Ramey :
> > It will be in bash-5.2-beta.
>
> Thank you for the clarification.
>
> > There is fairly extensive documentation in the current version of the
> > texinfo manual. Take a look; tell me what you think.
>
> Sorry, I hadn't checked the bashref.html of the devel branch. Now I
> have read the description. I think this is sufficiently clear, and in
> particular, these examples are very useful to understand the actual
> behavior. I like it. I couldn't find similar explanations or examples
> for glob operators (*, ?, [, @(), etc.) of ${var#pat}, ${var%pat}, and
> ${var/pat} and anchors # and % of ${var/#pat} and ${var/%pat}, but
> maybe we can have similar examples also for those pattern strings.
>
> --
> Koichi
>
>
Re: Bash not escaping escape sequences in directory names
i wanna add only few here, one i observed and was discussed a bit that is, also in declare -p, *sometimes* control chars arent escaped in my case they were messing terminal up after -p other case other dude, its output was escaped .. On Wed, Jan 19, 2022, 04:35 Josh Harcombe wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux computator 5.10.89-1-MANJARO #1 SMP PREEMPT Wed Dec 29 > 18:09:17 UTC 2021 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 > Patch Level: !PATCHLEVEL! > Release Status: alpha > > Description: > Note: this happens on 5.1 release version as well and probably many other > previous versions > If a folder that is being displayed as part of the PS1 prompt contains > escape sequences, bash will interpret them literally instead of escaping > them like zsh does for example. Escape sequences should be fine if directly > part of the prompt string and I'm not aware of any way for this to cause > issues other than messing with the prompt string in potentially unexpected > ways. > I would consider this a bug but it's possible there's an intended use case > for it. > > Repeat-By: > This is a silly little use case which gives the illusion of a root shell, > with the colours changed and the end of the original prompt hidden. > > [computator ~]$ echo -e "\"\r\x1b[1;31m[computator > \x1b[1;36mjoshh\x1b[1;31m]#\x1b[0;37m\x1b[8m\"" | xargs mkdir > [computator ~]$ cd ^M^[\[1\;31m\[computator\ > ^[\[1\;36mjoshh^[\[1\;31m\]#^[\[0\;37m^[\[8m/ > [computator joshh]# > > Fix: > Haven't looked deeply into the bash internals but sanitizing the directory > name (along with other user-controlled substitutions in the prompt) should > work. >
Re: bash dislikes empty functions or flow control bodies
what i meant to detail more is
;
where is the cmd.. synatx err, obviously
On Tue, Jan 18, 2022, 17:23 Alex fxmbsw7 Ratchev wrote:
> as you may see
>
> e() { ; }
>
> and sadly
>
> e() { }
>
> is simply invalid code, as the others say its by posix sh and mr bash wont
> digg it i guess
>
> On Tue, Jan 18, 2022, 12:46 wrote:
>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
>> -Werror=format-security -Wall
>> uname output: Linux latitude 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2
>> (2021-12-18) x86_64 GNU/Linux
>> Machine Type: x86_64-pc-linux-gnu
>>
>> Bash Version: 5.1
>> Patch Level: 16
>> Release Status: release
>>
>> Description:
>> Even if descriptions of situations where this problem occurs may sound
>> contrived, those situation exist and require me to catch this problem
>> with additional code:
>>a: defining an empty function will throw a syntax error
>>b: defining an empty bodies flow control construct will thow a syntax
>> error
>>
>> While it may be debatable whether such construct could serve any purpose
>> (they actually can), perceived lack of purpose doesn't qualify them as
>> syntactically wrong. They aren't. Would they be syntactically wrong,
>> the syntax error would continue to exist after adding a harmless
>> "no operation" equivalent.
>>
>> You may justifiable ask "so why not simply use the workaround by adding
>> a no operation equivalent" - answer is that it may not be me in person
>> creating a function or a flow control construct - the script may do too,
>> in accordance with input it received (this is the mentioned part where the
>> description may sound contrived, but isn't). Therefore I must protect the
>> script at this point from generating empty functions or flow control
>> constructs.
>>
>> You may have guessed here that this is going towards some sort of meta
>> programming, and a fuller view of the reason for reporting the bug can be
>> obtained at https://github.com/Bushmills/yoda, specifically
>> at https://github.com/Bushmills/yoda/issues/7
>> Measures to circumvent the problem can be found in file
>> https://github.com/Bushmills/yoda/blob/main/yoda at around line 1900
>> (at this time) on those lines with text "empty function" in the
>> description
>>
>>
>> Repeat-By:
>> bar() { ; }
>> foo() { if true; then ; fi; }
>> foo() { while :; do ; done; }
>>
>> Fix:
>> In cases where this problem arises, I tend to synthesise the closest
>> approximation of a "no operation" I know about, which is ":":
>> bar() { :; }
>> foo() { if true; then :; fi; }
>> foo() { while :; do :; done; }
>>
>>
>>
>>
>>
Re: bash dislikes empty functions or flow control bodies
as you may see
e() { ; }
and sadly
e() { }
is simply invalid code, as the others say its by posix sh and mr bash wont
digg it i guess
On Tue, Jan 18, 2022, 12:46 wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -Wall
> uname output: Linux latitude 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2
> (2021-12-18) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
> Even if descriptions of situations where this problem occurs may sound
> contrived, those situation exist and require me to catch this problem
> with additional code:
>a: defining an empty function will throw a syntax error
>b: defining an empty bodies flow control construct will thow a syntax
> error
>
> While it may be debatable whether such construct could serve any purpose
> (they actually can), perceived lack of purpose doesn't qualify them as
> syntactically wrong. They aren't. Would they be syntactically wrong,
> the syntax error would continue to exist after adding a harmless
> "no operation" equivalent.
>
> You may justifiable ask "so why not simply use the workaround by adding
> a no operation equivalent" - answer is that it may not be me in person
> creating a function or a flow control construct - the script may do too,
> in accordance with input it received (this is the mentioned part where the
> description may sound contrived, but isn't). Therefore I must protect the
> script at this point from generating empty functions or flow control
> constructs.
>
> You may have guessed here that this is going towards some sort of meta
> programming, and a fuller view of the reason for reporting the bug can be
> obtained at https://github.com/Bushmills/yoda, specifically
> at https://github.com/Bushmills/yoda/issues/7
> Measures to circumvent the problem can be found in file
> https://github.com/Bushmills/yoda/blob/main/yoda at around line 1900
> (at this time) on those lines with text "empty function" in the description
>
>
> Repeat-By:
> bar() { ; }
> foo() { if true; then ; fi; }
> foo() { while :; do ; done; }
>
> Fix:
> In cases where this problem arises, I tend to synthesise the closest
> approximation of a "no operation" I know about, which is ":":
> bar() { :; }
> foo() { if true; then :; fi; }
> foo() { while :; do :; done; }
>
>
>
>
>
