retrieving invocation arguments

retrieving invocation arguments

[Adam Spiers]

What's the best way of retrieving the arguments with which zsh was
invoked?  It doesn't appear to be stored in any parameter set by the
shell.  Worth doing?

Thanks,

Adam

Re: retrieving invocation arguments

[Bart Schaefer]

On Sep 14,  9:42pm, Adam Spiers wrote:
}
} What's the best way of retrieving the arguments with which zsh was
} invoked?

By examining $0, $-, and $*.  This is imperfect; $- doesn't tell you
what options were turned off.  However, in a non-interactive shell,
the only interesting option that is on by default is BG_NICE (-6).  It
is also not possible to get the command argument to -c, and when -c is
given the first non-option argument after the command to -c becomes $0
rather than being included in $*.  That is,

    zsh -fc 'echo $0' foo

will print "foo".

The best way to detect whether -c was given appears to be

    [[ -o shinstdin && ! -o interactive ]]

and to find out whether $0 is really an argument following the command,

    [[ $# -gt 0 || $0:t != $ZSH_NAME ]]

Of course you can fool that, e.g.

    zsh -c '[[ $# -gt 0 || $0:t != $ZSH_NAME ]] && echo Got $0' zsh

won't print anything, but that's a pretty obscure case.

} It doesn't appear to be stored in any parameter set by the shell.

AFAIK this is true of all shells.

} Worth doing?

It wouldn't be particularly difficult, but what's the application you
have in mind?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: retrieving invocation arguments

[Sweth Chandramouli]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Sat, Sep 15, 2001 at 05:34:27PM +0000, Bart Schaefer wrote:
> On Sep 14,  9:42pm, Adam Spiers wrote:
> }
> } What's the best way of retrieving the arguments with which zsh was
> } invoked?
> 
> By examining $0, $-, and $*.  This is imperfect; $- doesn't tell you
> what options were turned off.
	Why can't you just parse the output of setopt?  I think
you and I had a thread about how to do that easily a couple of years
ago; it should be in the archives, and it wouldn't be hard to modify.

	-- Sweth.

-- 
Sweth Chandramouli ; <svc@sweth.net>
President, Idiopathic Systems Consulting

[-- Attachment #2: Type: application/pgp-signature, Size: 236 bytes --]

Re: retrieving invocation arguments

[Adam Spiers]

Bart Schaefer (schaefer@brasslantern.com) wrote:
> On Sep 14,  9:42pm, Adam Spiers wrote:
> } What's the best way of retrieving the arguments with which zsh was
> } invoked?

[lots of remarkably helpful info snipped]

It continually staggers me how helpful the zsh-users are.  So many
times I've seen a simple question asked, and answers come back in
glorious detail.  Thanks Bart and everyone else for this; I think it's
a huge asset to zsh.

> } It doesn't appear to be stored in any parameter set by the shell.
> } Worth doing?
> 
> It wouldn't be particularly difficult, but what's the application you
> have in mind?

Nothing more complex than being able type `restart' to restart the
shell exactly how it was invoked.  Currently I have

  restart () {
      exec $SHELL "$SHELL_ARGS" "$@"
  }

and I do

  export SHELL_ARGS="$@"

in my ~/.switch_shell (run from bash).

Re: retrieving invocation arguments

[Peter Stephenson]

Sweth Chandramouli wrote:
> On Sat, Sep 15, 2001 at 05:34:27PM +0000, Bart Schaefer wrote:
> > On Sep 14,  9:42pm, Adam Spiers wrote:
> > }
> > } What's the best way of retrieving the arguments with which zsh was
> > } invoked?
> > 
> > By examining $0, $-, and $*.  This is imperfect; $- doesn't tell you
> > what options were turned off.
> 	Why can't you just parse the output of setopt?  I think
> you and I had a thread about how to do that easily a couple of years
> ago; it should be in the archives, and it wouldn't be hard to modify.

Or use the $options array from zsh/parameter.  Here's a function that saves
your options to a file; you just source that file to restore the options.
(The for-loop uses new 4.1 syntax, it's not too hard to make it
backward-compatible.)

## begin saveopts
zmodload -e zsh/parameter 

# guard against ksh array syntax being in force
local saveopts
# N.B. $saveopts is normal array
set -A saveopts ${(kv)options}

emulate -L zsh

if [[ $# != 1 ]]; then
  print "Usage: saveopts save_file" >&2
  return 1
fi

local savefile=$1
shift

local key val onlist offlist
onlist=()
offlist=()

for key val in $saveopts; do
  [[ $key = (interactive|shinstdin|stdin) ]] && continue
  if [[ $val = on ]]; then
    onlist=($onlist $key)
  else
    offlist=($offlist $key)
  fi
done

{
  print -r setopt ${(pj. \\\n.)${(o)onlist}}
  print
  print -r unsetopt ${(opj. \\\n.)${(o)offlist}}
} >$savefile
## end saveopts

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: retrieving invocation arguments

[Bart Schaefer]

On Sep 17, 12:07pm, Peter Stephenson wrote:
} Subject: Re: retrieving invocation arguments
}
} Or use the $options array from zsh/parameter.  Here's a function that saves
} your options to a file; you just source that file to restore the options.
} (The for-loop uses new 4.1 syntax, it's not too hard to make it
} backward-compatible.)

It's also not hard to do away with it entirely!

  ## begin saveopts
  emulate -L zsh	# This takes care of ksharrays et al.

  # I'm not sure what PWS was doing with zmodload -e ...
  zmodload -i zsh/parameter || return $?

  if [[ $# != 1 ]]; then
    print "Usage: saveopts save_file" >&2
    return 1
  fi

  local x='(interactive|shinstdin|stdin)'
  {
    print -r setopt ${(pj. \\\n .)${(ok)options[(R)on]:#$~x}}
    print -r unsetopt ${(pj. \\\n .)${(ok)options[(R)off]:#$~x}}
  } > $1
  ## end saveopts

Of course none of this answers the original question, because by the time
the user gets to execute any shell code the options may have been changed
by /etc/zshenv.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: retrieving invocation arguments

[Peter Stephenson]

Bart Schaefer wrote:
>   ## begin saveopts
>   emulate -L zsh	# This takes care of ksharrays et al.

It also screws everything up completely, appearing at that point.  That's
why I tried to do the minimum, saving the options to an ordinary array,
first.

>   # I'm not sure what PWS was doing with zmodload -e ...

I can't spell `-i'.

> Of course none of this answers the original question, because by the time
> the user gets to execute any shell code the options may have been changed
> by /etc/zshenv.

OK, I missed the point that Adam wants to restart the shell as it was
invoked, rather than as it now is.  You can argue which is more useful.
If you don't use -f, you can at least arrange to restart it as it was after
the startup scripts finished the last time, which is equivalent if you want
to prepare a given environment.  With -f you're more stuck.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: retrieving invocation arguments

[Bart Schaefer]

On Sep 17,  4:38pm, Peter Stephenson wrote:
} Subject: Re: retrieving invocation arguments
}
} Bart Schaefer wrote:
} >   ## begin saveopts
} >   emulate -L zsh	# This takes care of ksharrays et al.
} 
} It also screws everything up completely, appearing at that point.  That's
} why I tried to do the minimum, saving the options to an ordinary array,
} first.

Right, sorry, I noticed that just after I'd sent the message.

I think actually that the "emulate" could just be discarded entirely from
my version.  All the joins and splits are explicit so shwordsplit doesn't
matter, pattern matching with (...|...) works even with kshglob, and there
are no ordinary arrays to be affected by ksharrays.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: retrieving invocation arguments

[Bart Schaefer]

On Sep 17, 11:23am, Adam Spiers wrote:
}
} Currently I have
} 
}   restart () {
}       exec $SHELL "$SHELL_ARGS" "$@"
}   }
} 
} and I do
} 
}   export SHELL_ARGS="$@"
} 
} in my ~/.switch_shell (run from bash).

Ah.  Well, "$@" doesn't include the option switches even in bash, and
bash has the same behavior as zsh with respect to $0 and the first non-
option argument following a -c command.  Even if you did have the option
switches, you couldn't use them if $SHELL had changed from the original
shell.

Also, "$SHELL_ARGS" is going to be one argument where the original "$@"
may have had several.

And I should repeat the warning about `export SHELL_ARGS="$@"' -- "$@"
is an array with each element quoted, so what you've really written is

    export SHELL_ARGS="$1" "$2" "$3" ...

which is probably not what you meant.  Using "$@" works in bash because it
treats the arguments to `export' as if they were assignment expressions;
but in zsh that requires `setopt kshtypeset' (4.0.2 and later).

Anyway, it's very difficult to restart the shell exactly as it was invoked
unless you stash the arguments very early in .zshenv and have a cooperative
/etc/zshenv.  Probably the best thing would be along the lines of:

    restart_saveargs() {
	local x='(interactive|shinstdin|stdin)'
	local -a on off
	typeset -ga restart_args restart_options
	on=( ${(ok)options[(R)on]:#$~x} )
	off=( ${(ok)options[(R)off]:#$~x}} )
	restart_options=(
	    ${on:+-o} ${(j.-o .)=on}
	    ${off:++o} ${(j.+o .)=off}
	)
	restart_args=( "$@" )
    }
    restart() {
        emulate -L zsh
	if [[ $SHELL:t = zsh* ]]; then
	    exec $SHELL $restart_options $restart_args
	else
	    exec $SHELL $restart_args
	fi
    }
    restart_saveargs "$@"

And now that's probably more glorious detail than I should have included.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: retrieving invocation arguments

[Sweth Chandramouli]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Mon, Sep 17, 2001 at 09:59:15PM +0100, Adam Spiers wrote:
> To give some context to this, some machines I use have RedHat
> brokenness in /etc/zshrc, which I avoid by invoking zsh with -d from
> my .switch_shell.  If I then tweak something in my .zshrc for
> instance, or cvs update and reinstall a new zsh, I want to be able to
> just type `restart' to get a fresh new shell, hence the need for
> restart preserving the -d option.
	Umm... if you know what the flag in question is, why not
just hardcode it into your restart function, or have your restart
function call you switch_shell routine, or one of a million other
ways to not have to parse the entire shell option list just to see if
an option that you know you want to set happens to be set?

	-- Sweth.

-- 
Sweth Chandramouli ; <svc@sweth.net>
President, Idiopathic Systems Consulting

[-- Attachment #2: Type: application/pgp-signature, Size: 236 bytes --]

Re: retrieving invocation arguments

[Adam Spiers]

Peter Stephenson (pws@csr.com) wrote:
> OK, I missed the point that Adam wants to restart the shell as it was
> invoked, rather than as it now is.  You can argue which is more useful.

To give some context to this, some machines I use have RedHat
brokenness in /etc/zshrc, which I avoid by invoking zsh with -d from
my .switch_shell.  If I then tweak something in my .zshrc for
instance, or cvs update and reinstall a new zsh, I want to be able to
just type `restart' to get a fresh new shell, hence the need for
restart preserving the -d option.

Re: retrieving invocation arguments

[Adam Spiers]

Sweth Chandramouli (svc@sweth.net) wrote:
> On Mon, Sep 17, 2001 at 09:59:15PM +0100, Adam Spiers wrote:
> > To give some context to this, some machines I use have RedHat
> > brokenness in /etc/zshrc, which I avoid by invoking zsh with -d from
> > my .switch_shell.  If I then tweak something in my .zshrc for
> > instance, or cvs update and reinstall a new zsh, I want to be able to
> > just type `restart' to get a fresh new shell, hence the need for
> > restart preserving the -d option.
>
> 	Umm... if you know what the flag in question is, why not
> just hardcode it into your restart function, or have your restart
> function call you switch_shell routine, or one of a million other
> ways to not have to parse the entire shell option list just to see if
> an option that you know you want to set happens to be set?

I'm already using a work-around.  I merely wanted to know if there was
a clean and totally generalised way to do it, because I don't use the
same options on all machines I use, and I'd rather not have to code a
different restart function for each one.

Re: retrieving invocation arguments

[Adam Spiers]

Bart Schaefer (schaefer@brasslantern.com) wrote:
> On Sep 17, 11:23am, Adam Spiers wrote:
> }
> } Currently I have
> } 
> }   restart () {
> }       exec $SHELL "$SHELL_ARGS" "$@"
> }   }
> } 
> } and I do
> } 
> }   export SHELL_ARGS="$@"
> } 
> } in my ~/.switch_shell (run from bash).
> 
> Ah.  Well, "$@" doesn't include the option switches even in bash

That's OK, that "$@" refers to the arguments passed to .switch_shell,
which are hard-coded in my .bashrc rather than being those bash was
invoked with.

> Also, "$SHELL_ARGS" is going to be one argument where the original "$@"
> may have had several.
> 
> And I should repeat the warning about `export SHELL_ARGS="$@"' -- "$@"
> is an array with each element quoted, so what you've really written is
> 
>     export SHELL_ARGS="$1" "$2" "$3" ...
> 
> which is probably not what you meant.  Using "$@" works in bash because it
> treats the arguments to `export' as if they were assignment expressions;
> but in zsh that requires `setopt kshtypeset' (4.0.2 and later).

Yes, I was aware of that problem, although I guess what I actually
meant to write was

  export SHELL_ARGS="$*"

which should be a bit better, but still not ideal.  Anyhow,
dissatisfaction with this whole approach was the main reason for
asking the original question.

> Anyway, it's very difficult to restart the shell exactly as it was invoked
> unless you stash the arguments very early in .zshenv and have a cooperative
> /etc/zshenv.

I don't (and won't) have a cooperative /etc/zshenv, which is why it
would be nice if zsh itself made the information easily retrievable,
if it wouldn't be hard to implement cleanly.

> And now that's probably more glorious detail than I should have included.

:-)