Re: strange 'delayed' aliases
On 12/22/09 5:18 PM, Jonathan Claggett wrote: > Hi all, > > I'm not sure if this is a bug or not but it certainly caught me by surprise. > I accidentally created an alias ending with a backslash and a newline today > and the resulting alias proceeded to grab the text on the line _after_ I ran > it. For example: > > *$* echo $BASH_VERSION > 4.0.33(1)-release > *$* alias x='echo \ > *>* ' > *$* x > *$* Hello, World! > Hello, World! > ** > Is this delayed response expected? I would think so, since you've inserted a command continuation (the escaped newline) into the command via the alias. It's the same as if you had typed *$* echo \ *>* Hello, World! The only unexpected part is the re-issuing of $PS1 as opposed to $PS2. I'll have to take a look at that. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Query regarding ${parameter:-word} usage
Hi,
I am moving from ksh93 to bash and have a question regarding the usage
of ${parameter:-word} parameter expansion.
In ksh, I use ${*:-.} as an argument to commands. For example:
function ll
{
ls --color -Flv ${*:-.}
}
This technique passes '.' as an arg to 'ls' if I didn't pass any args on
the command line (as I'm sure you all already know). But this does not
work with bash; nor have I been able to come up with a technique that
accomplishes the same thing. My only workaround so far is to put an
'if' loop around the 'ls' that tests $# and takes the appropriate branch
depending on the number of args (i.e., 0 or non-zero).
Any suggestions would be welcomed. Thanks in advance.
--
Mun
Re: Query regarding ${parameter:-word} usage
On Wednesday 23 December 2009 19:51:02 Mun wrote:
> I am moving from ksh93 to bash and have a question regarding the usage
> of ${parameter:-word} parameter expansion.
>
> In ksh, I use ${*:-.} as an argument to commands. For example:
>
>function ll
>{
> ls --color -Flv ${*:-.}
>}
>
> This technique passes '.' as an arg to 'ls' if I didn't pass any args on
> the command line (as I'm sure you all already know). But this does not
> work with bash; nor have I been able to come up with a technique that
> accomplishes the same thing. My only workaround so far is to put an
> 'if' loop around the 'ls' that tests $# and takes the appropriate branch
> depending on the number of args (i.e., 0 or non-zero).
your code works fine for me
$ ll() { ls --color -Flv "$@:-.}" ; }
$ ls() { echo "$@" ; }
$ ll
--color -Flv .
$ ll moo
--color -Flv moo
-mike
signature.asc
Description: This is a digitally signed message part.
Re: Query regarding ${parameter:-word} usage
Mun wrote:
I am moving from ksh93 to bash and have a question regarding the usage
of ${parameter:-word} parameter expansion.
In ksh, I use ${*:-.} as an argument to commands. For example:
function ll
{
ls --color -Flv ${*:-.}
}
This technique passes '.' as an arg to 'ls' if I didn't pass any args on
the command line (as I'm sure you all already know). But this does not
work with bash; nor have I been able to come up with a technique that
accomplishes the same thing. My only workaround so far is to put an
'if' loop around the 'ls' that tests $# and takes the appropriate branch
depending on the number of args (i.e., 0 or non-zero).
Any suggestions would be welcomed. Thanks in advance.
Not sure why the above doesn't work, though you probably mean to use
"$@" and not $* (presence/absence of ""s is intentional). This seems to
work for me:
function ll
{
ls --color -Flv "${@:-.}"
}
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"It's not easy for [Microsoft] to accept [competing fairly]"
-- Dave Heiner (a Microsoft VP, paraphrased)
Re: Query regarding ${parameter:-word} usage
On Dec 23, 6:51 pm, Mun wrote:
> Hi,
>
> I am moving from ksh93 to bash and have a question regarding the usage
> of ${parameter:-word} parameter expansion.
>
> In ksh, I use ${*:-.} as an argument to commands. For example:
>
> function ll
> {
> ls --color -Flv ${*:-.}
> }
>
> This technique passes '.' as an arg to 'ls' if I didn't pass any args on
> the command line (as I'm sure you all already know). But this does not
> work with bash; nor have I been able to come up with a technique that
> accomplishes the same thing. My only workaround so far is to put an
> 'if' loop around the 'ls' that tests $# and takes the appropriate branch
> depending on the number of args (i.e., 0 or non-zero).
>
> Any suggestions would be welcomed. Thanks in advance.
>
> --
> Mun
"This does not work with Bash" - In what way? It works fine for me.
Re: Query regarding ${parameter:-word} usage
Hi,
Thanks for your replies.
Please see my comments below.
On Wed, Dec 23, 2009 at 05:30 PM PST, Matthew wrote:
MW>
MW>
MW> Mun wrote:
MW> > I am moving from ksh93 to bash and have a question regarding the usage
MW> > of ${parameter:-word} parameter expansion.
MW> >
MW> > In ksh, I use ${*:-.} as an argument to commands. For example:
MW> >
MW> > function ll
MW> > {
MW> >ls --color -Flv ${*:-.}
MW> > }
MW> >
MW> > This technique passes '.' as an arg to 'ls' if I didn't pass any args on
MW> > the command line (as I'm sure you all already know). But this does not
MW> > work with bash; nor have I been able to come up with a technique that
MW> > accomplishes the same thing. My only workaround so far is to put an
MW> > 'if' loop around the 'ls' that tests $# and takes the appropriate branch
MW> > depending on the number of args (i.e., 0 or non-zero).
MW> >
MW> > Any suggestions would be welcomed. Thanks in advance.
MW>
MW> Not sure why the above doesn't work, though you probably mean to use
MW> "$@" and not $* (presence/absence of ""s is intentional). This seems to
MW> work for me:
MW>
MW> function ll
MW> {
MW> ls --color -Flv "${@:-.}"
MW> }
I tried the above and got the following error:
bash: $@: unbound variable
Note that I am running the following version:
GNU bash, version 4.0.0(1)-release (x86_64-unknown-linux-gnu)
and my options are set as shown below.
Keep in mind that I'm porting my ksh environment to bash, so perhaps I
have something messed up in my environment. If the above is supposed to
work, then I'll try some additional experiments after the holidays and
see if I can narrow down the issue.
allexport on
braceexpand on
emacs off
errexit off
errtraceoff
functrace off
hashall on
histexpand on
history on
ignoreeof on
interactive-commentson
keyword off
monitor on
noclobber on
noexec off
noglob off
nolog off
notify off
nounset on
onecmd off
physicaloff
pipefailoff
posix off
privileged off
verbose off
vi on
xtrace off
Happy Holidays,
--
Mun
Re: strange 'delayed' aliases
On Dec 23, 7:34 am, Chet Ramey wrote: > I would think so, since you've inserted a command continuation (the escaped > newline) into the command via the alias. It's the same as if you had typed > > *$* echo \ > *>* Hello, World! > > The only unexpected part is the re-issuing of $PS1 as opposed to $PS2. > I'll have to take a look at that. It certainly seems to be related to command continuations. Here are a few more symptoms: 1) Text on the same line as the alias is run directly as a separate command. Bash doesn't see it as part of the original command: $ x Hello $ World! Hello: command not found 2) Adding text to the second line of the alias causes the alias to run immediately but the added text is ignored: $ alias x='echo \ > Hello' $ x $ 3) Adding text before the continuation in the alias causes the command history to report the second line as a separate command: $ alias x='echo Hello, \ > ' $ x $ World! Hello, World! $ history 2 481 x; World! 482 history 2 Hope this helps. - Jonathan
Re: Query regarding ${parameter:-word} usage
Mun schrieb: > nounset on Something sets -u in your startup scripts (or in the script or whatever)
Re: Query regarding ${parameter:-word} usage
Hi Jan, On Wed, Dec 23, 2009 at 10:52 PM PST, Jan Schampera wrote: JS> JS> JS> Mun schrieb: JS> JS> > nounset on JS> JS> Something sets -u in your startup scripts (or in the script or whatever) That's it! I'm not sure why I had nounset being turned on in my .bash_profile, but there it was. Thanks so much to everyone who replied for the help! -- Mun
