Re: is it a bug
On 2020/11/16 11:02, Alex fxmbsw7 Ratchev wrote:
on my way for a new paste
Anytime you start going over multiple lines in an alias, you
need to consider the use of a function, where 'need' would ideally
increase in proportion to the number of lines you are including.
For increased readability, I took out 'aal' being prepended to
every variable except the two usages of 'aal[...]' where I substituted
'foo' for 'aal'. NOTE: the code seems to use 'foo' (or 'aal') without it
being initialized.
The main oddity I found was that if (in my version),
t=""
is on the same line as 'res=()', I get the error with unexpected ';'
since it doesn't seem to parse the 'for' statement's "for", so the
semi after it is unexpected.
For some strange reason, the parsing of the array doesn't break off
at the space, in fact, when the lines are split, the alias seems
to lose some spacing (note 'res=t='):
executing alias +ax
res=t=
alias -- "t="
This seemed to be the minimum difference between a working & non working
case. Either (for no error):
an_alias='res=()
t=""
for ci in "${!foo[@]}"; do \
or (to reproduce error):
an_alias='res=() t=""
for ci in "${!foo[@]}"; do \
error I got was:
./aldef.sh: array assign: line 23: syntax error near unexpected token `;'
./aldef.sh: array assign: line 23: `res=() t=""
It is doing something weird -- I suspect that
alias expansion is expanding the right side as 'text' and not
as code that gets interpreted when the substitution occurs.
Try reserving aliases where it is needed (something a function can't do)
or where it helps legibility.
Hope this helps...ohincluding the version that gives an error.
To see version that works, split the 't=""' to be on the line
below the 'res=()'.
-linda
aldef.sh
Description: Bourne shell script
Re: is it a bug
On Mon, Nov 16, 2020 at 9:38 PM Robert Elz wrote:
>
> Personally I'd go further and suggest that no-one should ever use aliases
> for anything, ever ...
>
I don't understand why people "hate" aliases so much. :) For me it's much
simpler/shorter than functions. And the "alias" command (without any
options) output is more compact than "declare -f". Just take a look at some
of my aliases (I have ~150 aliases in total):
alias B='builtin'
alias C='command'
alias D='date'
alias E='export'
alias F='find'
alias G='git'
alias H='history'
alias I='ifconfig'
alias K='killall'
alias L='less'
alias M='LC_ALL=C MANWIDTH=$(( COLUMNS > 120 ? 120 : COLUMNS )) man'
alias N='netstat'
alias O='openssl'
alias P='patch'
alias R='route'
alias T='touch'
alias U='uname'
alias V='echo $BASH_VERSION'
alias W='watch'
alias X='screen -X'
alias Z='reset'
alias a='alias'
alias b='builtin cd -'
alias c='clear'
alias d='diff'
alias e='echo'
alias f='file'
alias g='grep'
alias h='help'
alias i='command info'
alias j='jobs'
alias k='kill'
alias l='ls -l'
alias m='make'
alias n='mount'
alias p='patch'
alias q='exit'
alias r='fc -s'
alias s='screen'
alias t='type'
alias u='umount'
alias v='vim'
alias x='xargs'
alias z='echo "${COLUMNS}x$LINES ${TERM:+($TERM)}"'
Re: [ping] declare -c still undocumented.
I must say, having increasingly elaborate forms of variable substitution to do things like this seems like poor design. I would favor constructions like $ BAZ=$( <<<$FOO some_program args ) Although I must say, I can't recall off the top of my head what Un*x utility best capitalizes the first letter of a string. Dale
Re: is it a bug
on my way for a new paste, i came over more such unexpected ';' token
errors, yet i seemed for workaround\compatibility to work around em by not
using ; at all, also on end of final done cause that error would appear
im still working on making my code acceptable
On Sat, Nov 14, 2020, 20:29 Alex fxmbsw7 Ratchev wrote:
> ( http://ix.io/2E6y )
> as.. the +al code worked and the +al alias was defined thru it.. just
> gives the shown ; error on use
>
>++ BEGINFILE ii.x7yz.1
>
> i code shortened coding codings, or at least wish to
> here in my x7yz control script i '. -- +al' a ./+al file which then sets
> aliases by file content, it does so
> but the resulting +al alias of itself says when usage syntax error ';'
> unexpected
> some other aliases work tho
>
> any ideas ?
>
>-- ENDFILE ii.x7yz.1 -=| 285 chars 55 words 6 lines
>++ BEGINFILE oo.x7yz.4
>
> root@boost:~/x7yz# . x7yz
> root@boost:~/x7yz# type +al
> +al is aliased to `aalres=( ) aalt=
> for caali in "${!aal[@]}" ; do
> aalres[caali]=$(
> printf %s "${aal[caali]}="
> if [[ -f ${aalt:=${aald[caali]:-${aal[caali]}}} ]] ; then
>exec cat -- "$aalt"
> else
>printf -- %s "$aalt"
> fi
> ) aalt=
> done
> [[ -v aalres[0] ]] &&
> alias -- "${aalres[@]}" ; '
> root@boost:~/x7yz# +al
> bash: syntax error near unexpected token `;'
> root@boost:~/x7yz#
>
>-- ENDFILE oo.x7yz.4 -=| 439 chars 63 words 18 lines
>++ BEGINFILE x7yz
>
> #!/bin/bash
> self=${BASH_SOURCE##/*} self=${self+$PWD/$self} self=${self:-$BASH_SOURCE} \
> dir=${self%/*} ; cd "$dir"
> shopt -s extglob globstar expand_aliases
> aal=( +al KWS +kw kwp )
> . -- "$aal"
> KWS
>
>
>-- ENDFILE x7yz -=| 198 chars 24 words 8 lines
>++ BEGINFILE +al
>
> aalres=( ) aalt=
> for caali in "${!aal[@]}" ; do
> aalres[caali]=$(
> printf %s "${aal[caali]}="
> if [[ -f ${aalt:=${aald[caali]:-${aal[caali]}}} ]] ; then
>exec cat -- "$aalt"
> else
>printf -- %s "$aalt"
> fi
> ) aalt=
> done
> [[ -v aalres[0] ]] &&
> alias -- "${aalres[@]}" ;
>
>-- ENDFILE +al -=| 278 chars 42 words 13 lines
>-- END of 4 pastes ( 1200 chars 184 words 45 lines
>
>
>
Re: set -e in subshell
you instruct the subshell to set -e, .. On Fri, Nov 13, 2020, 17:16 Aron Griffis wrote: > GNU bash, version 5.0.17(1)-release (x86_64-redhat-linux-gnu) > > $ (set -e; false; echo BANG) || echo whimper > BANG > > $ (set -e; false; echo BANG); echo whimper > whimper > > The || after the subshell seems to prevent set -e from being effective > inside the subshell. > > Is this a bug or does it make sense in a way I don't understand? > > Thanks, > Aron >
Re: is it a bug
Date:Mon, 16 Nov 2020 08:49:21 -0500 From:Greg Wooledge Message-ID: <20201116134921.gn...@eeg.ccf.org> | If a bug can actually be pinpointed and demonstrated, | I'm sure Chet would care. Chet might. I don't. I doubt many others do. | It's too convoluted. Just write a simple two- or | three-line demonstration of the problem. Agree that is better, but some bugs don't ever manifest under those conditions. I have had bugs (not in bash) that take pages of code to reproduce. I suspect this might be one like that. kre
Re: is it a bug
On Mon, Nov 16, 2020 at 08:37:05PM +0700, Robert Elz wrote: > Dale's point, with which I agree, is that you shouldn't even be attempting > using aliases for things like that. If there is some bug there, I don't > care, and I doubt anyone else does either. If a bug can actually be pinpointed and demonstrated, I'm sure Chet would care. My problem with this thread is that I can't make any sense of the original bug report at all. It's too convoluted. Just write a simple two- or three-line demonstration of the problem. Or better still, describe what the goal is. "I have some code in a file which defines aliases, and I want to use those in my script" -- well then, simply source that file.
Re: is it a bug
Date:Mon, 16 Nov 2020 13:52:55 +0100 From:Alex fxmbsw7 Ratchev Message-ID: | small conclusion: . code works, eval "$( < file )" worked, but alias | version not without empty newline Dale's point, with which I agree, is that you shouldn't even be attempting using aliases for things like that. If there is some bug there, I don't care, and I doubt anyone else does either. Personally I'd go further and suggest that no-one should ever use aliases for anything, ever ... aliases originated in csh (or perhaps ashell which preceded it) which had no functions, and lacked the syntactic ability to really add them - aliases were its mechanism to allow users to define new commands that affect the state of the shell itself. ksh apparently copied that (part of what csh allowed), but then created functions, which are a much better method to achieve the same goal - aliases should have been deleted when that happened. But weren't (it isn't as if ksh/bash (or POSIX) aliases are powerful enough to actually replace csh aliases in general, whereas functions are). The only use for aliases that can't be done with functions is to create new sh syntax (as some combination of existing syntax) which is a spectacularly bad idea, and should never be actually used by anyone, for anything, other than demonstrating just how crazy it really is. I generally stop reading bash example code as soon as it starts using arrays. As best I can guess is that you're writing an alias for defining aliases, if you just used a function instead (as Dale suggested) this would be much simpler and cleaner. But once you've done that, you should throw it away, as you shouldn't be using aliases at all, you really have no need for some shorthand method of making them. kre
Re: is it a bug
thank you sir dale, while i was cleaning up the code for another paste with more details i came across that when i add a empty newline before the first for, the bug line disappears small conclusion: . code works, eval "$( < file )" worked, but alias version not without empty newline .. im sorry i have a hard time typing on android stuff long On Mon, Nov 16, 2020, 05:18 Dale R. Worley wrote: > Alex fxmbsw7 Ratchev writes: > > i code shortened coding codings, or at least wish to > > here in my x7yz control script i '. -- +al' a ./+al file which then > > [...] > > any ideas ? > > This is *really* hard to understand. None of the names of files, > variables, or functions describes what they are intended to do, and > there are no comments that do so. It is likely that much of the code > could be removed and still have an illustration of the problem case. > > Also, it is generally recommended that aliases be replaced with > functions, as the processing of functions has better syntactic and > semantic behavior. > > Dale >
