Re: problem anomalies , possibly aliases related
sorry for possible negative effected texting
i d wish to discuss , why aliases are a big gain , and why so my indenting
i ve been in #bash and #awk since 200[012] , where such negative english
texting like me getting banned there for years , ..
i did learn back then , and did , and do answer bash awk q s with top code
( to my subjective level )
many of my res es was marked as 'impossible' or 'shitty old sh like
workaround' , by .. uhm whoever
later then went unfriendly and so i quit the , english wrong chat
.. i understand here may be not the place for such a discussion , whenever
u wanted to join .. i just .. began mentioning it here
u know a place to post pro tech topics ? or smth ?
On Thu, Jul 20, 2023, 8:22 AM Martin D Kealey
wrote:
> Hi Alex
>
> Aliases are not functions, and they don't work the same way.
>
> A function is like a separate script, except that it runs in the same
> process & context as the caller. Its meaning is determined as the script
> RUNS.
> An alias is quite different: it replaces tokens while the script is being
> PARSED.
>
do u know , that is around the big process where the bash determines when
thers errs in the file to exec an err msg and fail to run
In particular,
> alias A='B ; C'
> D && A
> will replace `A` with `B ; C` to get `D && B ; C` which is THEN parsed
> into the equivalent of:
> { D && B ; } ; C
>
> (Same if you use a line break instead of a semicolon.)
>
a yes my detail thinking error , already the ~third time in my time
thank u much bout pointing this out
.. i .. thought .. aliases are text replacements
what i didnt know is .. whats a bit obvious .. bash replaces em when read ,
not just in [[ $? 0 , but completly regardless of the code
.. then makes sense that there continue .. my bug
The output of `set -x` reflects the structure of the code, not the literal
> text. We expect it to exclude comments, extra blank lines, and names of
> aliases where they are used.
>
> Unless you actually need to modify how a script is PARSED, don't use
> aliases; use functions instead.
>
im an old tech style veteran , aliases are there to be learned
noone could still force me to use limited ( due to wrong / outdated rules )
instead unlimited
i mean , u say , like many else , aliases arent to be used
is that cause many fails ?
its pure braindamage
alike the sayings 'bash is no programming language' many times and tho just
from a few users
i contered it the same way .. bs nonsense
-Martin
>
> PS: please use structure-indicative indentation when showing examples.
>
ah oh my spacing ( since i dont tab )
i did that since long for long
now , same as i thought back then about ur tabbing finding it cool
its a massive non maintainable desaster
and as i thought cool , my ' cool ' about my current style
cmds=0spaces
[[ cond ]] && {
cmd1
cmd2
}
for i in bla ; do
[[ foo ]] &&
a ||
b
done
cmds no space
no op / conditional +1 space
id call it reverse tabbing , or some other texting
its the delight
have to think 0.1% about wtf id indent ( not happily with it ) on old style
ill todo a better text description , and positive sides of it
greets
>
Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023, 01:42 alex xmb ratchev wrote:
>
>
> 2. it says [[ ! -d then ' continue ' .. where is cp
> i call no , not c , ...
> 1. cp missing
> 2. the [[ ! -d return to continue looks bug wrong
>
Try putting the code that uses the alias into a function, and then print
the function definition. You'll see how it's being expanded.
Using Martin's example:
$ alias A='B ; C'
$ f() { D && A; }
$ declare -p -f f
f ()
{
D && B;
C
}
Sounds like you want all the commands in the alias to be executed as a
group -- so you can just write it as one:
alias bad='{ echo fail; continue; }'
>
Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023, 10:03 AM Grisha Levit wrote:
>
>
> On Thu, Jul 20, 2023, 01:42 alex xmb ratchev wrote:
>
>>
>>
>> 2. it says [[ ! -d then ' continue ' .. where is cp
>> i call no , not c , ...
>> 1. cp missing
>> 2. the [[ ! -d return to continue looks bug wrong
>>
>
> Try putting the code that uses the alias into a function, and then print
> the function definition. You'll see how it's being expanded.
>
> Using Martin's example:
>
> $ alias A='B ; C'
> $ f() { D && A; }
> $ declare -p -f f
> f ()
> {
> D && B;
> C
> }
>
> Sounds like you want all the commands in the alias to be executed as a
> group -- so you can just write it as one:
>
> alias bad='{ echo fail; continue; }'
>
alias bad .. :)) ... ye that s my only fix to it
else id use funcs , but i see.only slowdown using those
esp. when i cant cont or break a loop
ill have , i hope , a ( selfcoded ) httpd again
full of public domain open sources codes , of me , and doc texts regarding
0 - 100 debian bash gawk
i urge , whoever runs such sites , to update them to the ( users ) current
knowledge
i find 100% of the google res inet useless untrue outdated , money monkey
written .. wrong
greets
>
Re: problem anomalies , possibly aliases related
the bugfixed version
that ran 24m long
On Thu, Jul 20, 2023, 10:08 AM alex xmb ratchev wrote:
>
>
> On Thu, Jul 20, 2023, 10:03 AM Grisha Levit wrote:
>
>>
>>
>> On Thu, Jul 20, 2023, 01:42 alex xmb ratchev wrote:
>>
>>>
>>>
>>> 2. it says [[ ! -d then ' continue ' .. where is cp
>>> i call no , not c , ...
>>> 1. cp missing
>>> 2. the [[ ! -d return to continue looks bug wrong
>>>
>>
>> Try putting the code that uses the alias into a function, and then print
>> the function definition. You'll see how it's being expanded.
>>
>> Using Martin's example:
>>
>> $ alias A='B ; C'
>> $ f() { D && A; }
>> $ declare -p -f f
>> f ()
>> {
>> D && B;
>> C
>> }
>>
>> Sounds like you want all the commands in the alias to be executed as a
>> group -- so you can just write it as one:
>>
>> alias bad='{ echo fail; continue; }'
>>
>
> alias bad .. :)) ... ye that s my only fix to it
> else id use funcs , but i see.only slowdown using those
> esp. when i cant cont or break a loop
>
> ill have , i hope , a ( selfcoded ) httpd again
> full of public domain open sources codes , of me , and doc texts regarding
> 0 - 100 debian bash gawk
>
> i urge , whoever runs such sites , to update them to the ( users ) current
> knowledge
>
> i find 100% of the google res inet useless untrue outdated , money monkey
> written .. wrong
>
> greets
>
>>
db3.2bash
Description: Binary data
Re: problem anomalies , possibly aliases related
On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote:
> Sounds like you want all the commands in the alias to be executed as a
> group -- so you can just write it as one:
>
> alias bad='{ echo fail; continue; }'
>
That right there USED to work as a function:
bad() { echo fail; continue; }
But then someone suggested allowing non-local break & continue was a bug,
and the few people who considered it couldn't think of even as simple an
example as that right there.
So it was "fixed", and now that function doesn't work. It sickens me that
the work-around is to enable alias expansion in scripts.
*Grumble*
-Martin
PS: and people think I'm crazy for wanting to write new stuff in Perl, in
preference to Bash. Bash as a language has nothing else going for it, so if
after 28 years I still can't consider it stable, what is the point?
>
Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023 at 11:03:35PM +1000, Martin D Kealey wrote:
> On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote:
>
> > Sounds like you want all the commands in the alias to be executed as a
> > group -- so you can just write it as one:
> >
> > alias bad='{ echo fail; continue; }'
> >
>
> That right there USED to work as a function:
>
> bad() { echo fail; continue; }
>
> But then someone suggested allowing non-local break & continue was a bug,
> and the few people who considered it couldn't think of even as simple an
> example as that right there.
>
> So it was "fixed", and now that function doesn't work. It sickens me that
> the work-around is to enable alias expansion in scripts.
>
> *Grumble*
The idea that this would "work" is quite surprising to me. The basic
idea of a function is that it does stuff and then returns you to the
point where you were when the function was called.
In other languages, would you expect that you might call a function,
and have that function reach upward through the call stack and manipulate
your control flow? Some languages might have features designed for
that (Tcl's "uplevel" command comes to mind), but these are exceptions,
and experienced programmers would use such features sparingly.
What you're really looking for is the behavior of a macro, rather than
a function. C has macros (#define), and so does bash (alias).
So, if this is the behavior you want, then do what xmb is doing. Turn
on alias expansions, and write your flow-controlling macros as aliases.
Use functions for the things that should work normally (no control flow
modifications or parser short-circuiting), and aliases for the weird,
quirky behaviors that wouldn't normally be allowed.
Re: problem anomalies , possibly aliases related
On Thu, 20 Jul 2023, 23:28 Greg Wooledge, wrote: > The idea that this would "work" is quite surprising to me. Shell functions are SO unlike functions in other languages that it surprises me that anyone would assume any particular parallel holds. Everything about them is dynamic: where they find variables (up frame by default unless you use "local"); even their very existence, which only begins when the flow of control passes over their definitions, and ends with unset -f. So when one reads the manual and it says "outer loop", there is no reason to assume this is referring to grammatical scope; dynamic scope makes just as much sense, and a quick test confirms it. Well, it DID confirm it. The basic idea of a function is that it does stuff and then returns you to > the point where you were when the function was called. > Except that it's not (at least, not since we mangled the mathematical word "function" to mean what we used to call "subroutine"). C has longjmp, and other languages have exceptions. Non-local break is a usable "Bash shaped" analogue of those. Not perfect, sure, but close enough to be useful. (Non-local continue is a logical extension of that.) Saying that this *ought* to be done using aliases is not reasonable, as it means forgoing the other stuff that functions can do, like taking parameters, declaring local variables, or returning a status. -Martin
Re: [PATCH] normalization tweaks for macOS
On 7/18/23 1:39 PM, Grisha Levit wrote: On Tue, Jul 18, 2023 at 9:55 AM Chet Ramey wrote: Unicode normalization on macOS has always been a pain in the ass. I can see that! This is the basic assumption that drives all the decisions: character input you get from the terminal is in NFC, and files from the file system (names and usually contents) are in NFD. I guess the point of this patch was that this assumption does not always hold -- neither file system names nor terminal input have any guaranteed normalization. I should have said keyboard input; pasted text can be NFD, as you show. So I'll go ahead with your patch, starting with the globbing changes. We're already not conformant with POSIX here, so what's a little bit more? Apple certainly didn't do anyone any favors with this. 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: problem anomalies , possibly aliases related
i most dont understand your text story
On Thu, Jul 20, 2023, 3:03 PM Martin D Kealey
wrote:
>
>
> On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote:
>
>> Sounds like you want all the commands in the alias to be executed as a
>> group -- so you can just write it as one:
>>
>> alias bad='{ echo fail; continue; }'
>>
>
> That right there USED to work as a function:
>
> bad() { echo fail; continue; }
>
ah cont in func
But then someone suggested allowing non-local break & continue was a bug,
> and the few people who considered it couldn't think of even as simple an
> example as that right there.
>
> So it was "fixed", and now that function doesn't work. It sickens me that
> the work-around is to enable alias expansion in scripts.
>
> *Grumble*
> -Martin
>
> PS: and people think I'm crazy for wanting to write new stuff in Perl, in
> preference to Bash. Bash as a language has nothing else going for it, so if
> after 28 years I still can't consider it stable, what is the point?
>
perl is simple and big .. i like
old around y2k when i tried hack some perl together
the public media , as many else , is every thing than perfect
perl i didnt see fpr years , as many other tho big links
about 28 years , u can see it as 1) specification
or 2) version
i just wanna say .. it still takes a while
>
Re: [PATCH] normalization tweaks for macOS
On Thu, Jul 20, 2023, 5:55 PM Chet Ramey wrote: > On 7/18/23 1:39 PM, Grisha Levit wrote: > > On Tue, Jul 18, 2023 at 9:55 AM Chet Ramey wrote: > >> Unicode normalization on macOS has always been a pain in the ass. > > > > I can see that! > > > >> This is the basic assumption that drives all the decisions: character > input > >> you get from the terminal is in NFC, and files from the file system > (names > >> and usually contents) are in NFD. > > > > I guess the point of this patch was that this assumption does not > > always hold -- neither file system names nor terminal input have any > > guaranteed normalization. > > I should have said keyboard input; pasted text can be NFD, as you show. > > So I'll go ahead with your patch, starting with the globbing changes. We're > already not conformant with POSIX here, so what's a little bit more? > > Apple certainly didn't do anyone any favors with this. > bad deals .. so sad .. so usual 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/ > > >
git amend commit with backticks on cli causes tty to crash
Hi,
I'm seeing this behavior on Fedora 38. Possibly it's just some user error
again, since i'm figuring out how to use vim and git at a slightly above
novice level. :-)
#+++
$ uname -a
Linux localhost-live 6.3.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun
9 15:21:11 UTC 2023 x86_64 GNU/Linux
$ vim --version | head -n 3
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 05 2023 00:00:00)
Included patches: 1-1607
Modified by
$ cat ~/.vimrc | grep -v ^'"'
set number
filetype plugin indent on
set tabstop=2
set shiftwidth=2
set expandtab
autocmd BufWritePost * execute '! if [[ -d ./.git ]] ; then git commit -S
-a --file=- --verbose ; fi'
$ git --version
git version 2.41.0
$ bash --version
GNU bash, version 5.2.15(1)-release (x86_64-redhat-linux-gnu)
$ xfce4-terminal --version
xfce4-terminal 1.0.4 (Xfce 4.18)
#+++
The first time I saw this bug, tty3 crashed and isn't available any more in
/dev/pts . Partially reproducing the bug, ttys have crashed but they become
available for use again when I press Ctrl-Shift-t from xfce4-terminal.
#+++
[liveuser@localhost-live ~]$ tty
/dev/pts/4
[liveuser@localhost-live ~]$ ls /dev/pts
0 1 2 4 ptmx
#+++
The original pre-amend commit message was 'LiveUsb1: At error handling, add
if block to `source ./functions.bash`'. From within vim (and tty6), I'd
place an additional '#' at line 30 and press ':w'.
#+++
30 # <> debug string ##
31
32 unset -f er_x rm_oa
33 function er_x(){ : ; local exit_code="$?" ; echo -e Error: "$@" >&2 ;
exit "${exit_code}"; }
34 ## rm_oa: '--' is placed at fn call
35 function rm_oa(){ :
"./LiveUsb1" 653L, 20976B written
:!if [[ -d ./.git ]] ; then git commit -S -a --file=- --verbose ; fi
(reading log message from standard input)
#+++
After pasting in the faulty commit message, pressing [enter] and [Ctrl-d],
git shows a standard message:
#+++
LiveUsb1: At error handling, add if block to `source ./functions.bash`
[main e02d0aa] LiveUsb1: At error handling, add if block to `source
./functions.bash`
1 file changed, 1 insertion(+), 1 deletion(-)
Press ENTER or type command to continue
#+++
I'd press [enter], vim would return to normal viewing mode and pressing
':q!' would close vim. Then I'd try (on tty5) to amend the commit message
by starting a string with a single quote and adding newlines within, based
on my understanding that git reads the first line of a commit messages a
something akin to a an email subject line, and then after an empty line,
the rest of the message is parsed by git as the "details" or "body" section
of the commit message.
#+++
[liveuser@localhost-live ~]$ git -S --amend -m 'LiveUsb1: Add `source
./functions.bash`
>
> LiveUsb1: At error handling, in if-fi block at line 23
>
#+++
But of course, I forgot the second single quote! Press [Ctrl-d].
#+++
bash: unexpected EOF while looking for matching `''
#+++
Add one single quote, press [Ctrl-d}; no response. Press [enter] and
[ctrl-d]:
#+++
bash: unexpected EOF while looking for matching `''
#+++
Press [ctrl-d] again and tab (tty 5) crashes.
#+++
[liveuser@localhost-live ~]$ ls /dev/pts
0 1 2 4 6 ptmx
[liveuser@localhost-live ~]$ tty
/dev/pts/4
# in xfce4-terminal: [ctrl]-[shift]-t
[liveuser@localhost-live ~]$ ls /dev/pts
0 1 2 4 5 6 ptmx
#+++
Wiley
"The bashful never learn, and the short tempered cannot teach." -- Talmud
Re: problem anomalies , possibly aliases related
On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote:
> C has longjmp, and other languages have exceptions. Non-local break is a
> usable "Bash shaped" analogue of those. Not perfect, sure, but close enough
> to be useful. (Non-local continue is a logical extension of that.)
>
> Saying that this *ought* to be done using aliases is not reasonable, as it
> means forgoing the other stuff that functions can do, like taking
> parameters, declaring local variables, or returning a status.
Well in any case, the behavior you wanted is not reliable across shells,
nor even across versions of bash.
unicorn:~$ cat foo
f() { echo f; break; }
for i in 1 2 3; do
echo "$i"
f
done
unicorn:~$ bash-4.3 foo
1
f
unicorn:~$ bash-4.4 foo
1
f
foo: line 1: break: only meaningful in a `for', `while', or `until' loop
2
f
foo: line 1: break: only meaningful in a `for', `while', or `until' loop
3
f
foo: line 1: break: only meaningful in a `for', `while', or `until' loop
unicorn:~$ dash foo
1
f
2
f
3
f
unicorn:~$ ksh foo
1
f
2
f
3
f
Since it's not possible to do it this way portably, I suggest that the
alias alternative would be the way to go.
Re: [PATCH] normalization tweaks for macOS
On Thu, Jul 20, 2023 at 11:54 AM Chet Ramey wrote:
> So I'll go ahead with your patch, starting with the globbing changes.
Thanks! BTW, changing quote_string_for_globbing to skip escaping
characters that don't need it makes globbing >2x faster in the case
that most of the pattern is a quoted string. This patch only skips
over non-ASCII characters (because that's all that was needed for the
normalization to work) but I wonder if you'd be interested in changes
to the function that would skip escaping ASCII characters that aren't
glob-special as well. I _think_ it would just be a slight variation
of the code that already does this for regexes but I haven't thought
about the edge cases carefully yet.
mkdir /tmp/new && cd /tmp/new
touch {0001..1000}
printf -v str %1000s; export str=${str// /π}
export TIMEFORMAT=%3lR
bash-devel -c 'time for i in {1..100}; { : "$str"*; }'
0m5.549s
bash-devel -c 'time for i in {1..100}; { : $str*; }'
0m1.936s
bash-patch -c 'time for i in {1..100}; { : "$str"*; }'
0m1.948s
bash-patch -c 'time for i in {1..100}; { : $str*; }'
0m1.926s
