Cursor jumps to leftmost column on trap ... SIGALRM
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
uname output: Linux .fraunhofer.de 5.15.12-200.fc35.x86_64
#1 SMP Wed Dec 29 15:03:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.1
Patch Level: 8
Release Status: release
Description:
The position of the cursor changes to the first column when bash,
running inside xterm, receives the signal SIGALRM
Expected behavior: No change in cursor position
Repeat-By:
# Start a bash in xterm w/o customizations
xterm -class nothing -e bash --norc &
# within this xterm, enter:
function sigalarm_test { echo -n ; } # define an empty signal handler
trap sigalarm_test SIGALRM# install the signal handler
echo $$ # report the shells PID
# in a different shell, send SIGALRM to the PID of the previously
started bash
kill -s SIGALRM PID # use the PID reported by 'echo
$$' above
=> now the cursor position jumps to the first column in the xterm
running bash
So far I've watched this behavior only with SIGALRM.
Re: Incorrect alias expansion within command substitution
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.
--
``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: Cursor jumps to leftmost column on trap ... SIGALRM
On 2/4/22 9:54 AM, Markus Schwarzenberg wrote: Bash Version: 5.1 Patch Level: 8 Release Status: release Description: The position of the cursor changes to the first column when bash, running inside xterm, receives the signal SIGALRM Thanks for the report. It's readline and bracketed paste. When readline gets the SIGALRM, it cleans up the terminal, resets the signal handler to what it was when it was called, and resends the SIGALRM to the current process. Part of that cleaning up the terminal involves taking it out of bracketed paste mode. The escape sequence that takes the terminal out of bracketed paste mode ends with carriage return (\r). Ironically, this is needed to ensure that the Linux terminal driver doesn't get confused about the physical cursor position. So far I've watched this behavior only with SIGALRM. It would probably happen with any signal for which readline installs a handler. For this case, since the signal handler doesn't do anything, it's enough to set readline's internal idea of the cursor position after writing the disable-bracketed-paste key sequence. The cursor will stay at position 0 until you do something that requires a redisplay, then the right thing will happen. In the general case, the application's signal handler can do just about anything, and the state of the display is indeterminate. Readline can't know. We can force a redisplay in the code that handles the return from the signal handler. That, however, has its own problems. If the application's signal handler doesn't do anything, forcing the cursor to a new line and forcing a redisplay will result in duplicated lines. (If we don't force a new line, we can potentially overwrite output from the application's signal handler.) I'll have to think about it. 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 2/3/22 4:20 PM, Robert Elz wrote: | and it's just | as clear that, let's say, implementations differ in this area. Aside from bash 5.2, not really. There are lots of implementation bugs are limitations, but not really any expectation that the here doc end word text can be modified (beyond quote removal). Wait, what are we talking about here? If we're talking about alias expansion inside here-document delimiters containing command substitutions, the only thing common is the error. If we're talking about whether or not the spaces are preserved in $( a b ), there are again several different outputs. | I'm comfortable with not supporting this use case. Fine, I doubt you'll ever encounter anything like that in the wild, but you are breaking backwards compat with bash up to 5.1 when you do that. The first half of your sentence mitigates the issue in the second half. I think it's more important to get the other posix conformance issue right. | > cat <<$(cat hello | > $(cat Ah. I use the opposite approach. It usually produces more effective results, especially if I need to start a debugger. -- ``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 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?
chet didnt you say there were no bugs ? =)
I didn't, but how is that relevant 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 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 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 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: Cursor jumps to leftmost column on trap ... SIGALRM
On Fri, 4 Feb 2022 13:19:37 -0500 Chet Ramey wrote: > On 2/4/22 9:54 AM, Markus Schwarzenberg wrote: > > > Bash Version: 5.1 > > Patch Level: 8 > > Release Status: release > > > > Description: > > The position of the cursor changes to the first column when > > bash, running inside xterm, receives the signal SIGALRM > > Thanks for the report. It's readline and bracketed paste. Interestingly, I can't reproduce the behavior myself on the following system (opensuse tumbleweed) Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fun> uname output: Linux XXX 5.15.12-1-default #1 SMP Wed Dec 29 14:50:16 UTC 2> Machine Type: x86_64-suse-linux-gnu Bash Version: 5.1 Patch Level: 12 Release Status: release [ ... ] > We can force a redisplay in the code that handles the return from the > signal handler. That, however, has its own problems. If the > application's signal handler doesn't do anything, forcing the cursor > to a new line and forcing a redisplay will result in duplicated > lines. (If we don't force a new line, we can potentially overwrite > output from the application's signal handler.) > > I'll have to think about it. I'd be happy with some command forcing redisplay, executed from within the handler as a workaround. Note: The example given in the bug description is just the simplest way to reproduce that behavior. Practically I've been using the SIGALRM handler for really a long period now (ca. 20 years). Usage: It's invoked from a xterm key binding and finally makes the running bash open a file guessed from the currently selected ls -l output line (or gcc error line, etc.). The observed readline behavior is quite new ( < 1 year). It didn't happen in older versions. Thanks, Markus Schwarzenberg
Re: Incorrect alias expansion within command substitution
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).
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.
| 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.
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.
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.
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 ))
and it should work fine (the here doc text ends with the exact same string,
spacing and all). Even the "except for parentheses" just means that any
parentheses that occur must balance correctly - otherwise the correct '))'
won't be detected.
kre
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 is no right complete shell construct to execute, then
cause random trash wont match
so its unmatched matcher
> and it should work fine (the here doc text ends with the exact same string,
> spacing and all). Even the "except for parentheses" just means that any
> parentheses that occur must balance correctly - otherwise the correct '))'
> won
Re: Incorrect alias expansion within command substitution
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.) -- ``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: Cursor jumps to leftmost column on trap ... SIGALRM
On 2/4/22 4:11 PM, Markus Schwarzenberg wrote: On Fri, 4 Feb 2022 13:19:37 -0500 Chet Ramey wrote: On 2/4/22 9:54 AM, Markus Schwarzenberg wrote: Bash Version: 5.1 Patch Level: 8 Release Status: release Description: The position of the cursor changes to the first column when bash, running inside xterm, receives the signal SIGALRM Thanks for the report. It's readline and bracketed paste. Interestingly, I can't reproduce the behavior myself on the following system (opensuse tumbleweed) It depends on whether or not bracketed paste is active. We can force a redisplay in the code that handles the return from the signal handler. That, however, has its own problems. If the application's signal handler doesn't do anything, forcing the cursor to a new line and forcing a redisplay will result in duplicated lines. (If we don't force a new line, we can potentially overwrite output from the application's signal handler.) I'll have to think about it. I'd be happy with some command forcing redisplay, executed from within the handler as a workaround. On a new line? Duplicating what was there before the SIGALRM? I think you'd be surprised at how many people would disagree with you. Note: The example given in the bug description is just the simplest way to reproduce that behavior. Practically I've been using the SIGALRM handler for really a long period now (ca. 20 years). Usage: It's invoked from a xterm key binding and finally makes the running bash open a file guessed from the currently selected ls -l output line (or gcc error line, etc.). The observed readline behavior is quite new ( < 1 year). It didn't happen in older versions. It coincided with the introduction of bracketed-paste, and you probably noticed it when bracketed-paste became the default. -- ``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: Cursor jumps to leftmost column on trap ... SIGALRM
On Fri, 4 Feb 2022 17:37:06 -0500 Chet Ramey wrote: > It depends on whether or not bracketed paste is active. Must admit I wasn't aware of this. And will think about whether I need it. > On 2/4/22 4:11 PM, Markus Schwarzenberg wrote: > > On Fri, 4 Feb 2022 13:19:37 -0500 > > Chet Ramey wrote: > > > > I'd be happy with some command forcing redisplay, executed from > > within the handler as a workaround. > > On a new line? Duplicating what was there before the SIGALRM? I think > you'd be surprised at how many people would disagree with you. Didn't mean on a new line, of course. Rather tought of a kind of redraw command. Markus
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
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
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/
