Re: Still problems with scriptname (presumably)

Re: Still problems with scriptname (presumably)

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > Peter Stephenson wrote:
> > > % zsh -c 'echo '\' this_is_not_the_command_name
> > > this_is_not_the_command_name:-1: unmatched '
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > this is the bit I object to, the error message is OK.
> > 
> > But then I tried ksh and bash. ksh doesn't give me an error (?!?) and
> > bash does the same as zsh currently does.
> 
> You're right, and in fact I've known about this for ages and mentioned it
> before and was just thinking about it today and the penny still didn't
> drop... Bourne shell derivatives when they use -c set $0 to the first
> argument.  That needs to be kept.  There's no reason for an option which
> will just add to the confusion.

You'll have noticed that my patch (still not committed) doesn't change 
$0, it just keeps that from being used as the `name' for printing
errors and warnings.

So... ;-)

(I'd be in favour of using the patch, the current behaviour looks so weird.)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Still problems with scriptname (presumably)

[Peter Stephenson]

Sven Wischnowsky wrote:
> You'll have noticed that my patch (still not committed) doesn't change 
> $0, it just keeps that from being used as the `name' for printing
> errors and warnings.
> 
> So... ;-)
> 
> (I'd be in favour of using the patch, the current behaviour looks so weird.)

Aha.  Confusion is a wonderful thing.  Yes, as far as internal management
of names goes that would be fine.  It's explicitly separate from argzero
anyway, because of the [no]functionargzero bodge, and I've taken to using
`print -P %N' to get function names in messages, so your patch would seem
to be a sensible way forward.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Still problems with scriptname (presumably)

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > You'll have noticed that my patch (still not committed) doesn't change 
> > $0, it just keeps that from being used as the `name' for printing
> > errors and warnings.
> > 
> > So... ;-)
> > 
> > (I'd be in favour of using the patch, the current behaviour looks so weird.)
> 
> Aha.  Confusion is a wonderful thing.  Yes, as far as internal management
> of names goes that would be fine.  It's explicitly separate from argzero
> anyway, because of the [no]functionargzero bodge, and I've taken to using
> `print -P %N' to get function names in messages, so your patch would seem
> to be a sensible way forward.

Well then...

Bye
 Sven

Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.1.1.51
diff -u -r1.1.1.51 init.c
--- Src/init.c	2000/03/23 04:22:57	1.1.1.51
+++ Src/init.c	2000/04/06 08:26:07
@@ -222,6 +222,7 @@
 		cmd = *argv;
 		opts[INTERACTIVE] &= 1;
 		opts[SHINSTDIN] = 0;
+		scriptname = ztrdup("zsh");
 	    } else if (**argv == 'o') {
 		if (!*++*argv)
 		    argv++;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Still problems with scriptname (presumably)

[Sven Wischnowsky]

Peter Stephenson wrote:

> % zsh -c 'echo '\' this_is_not_the_command_name
> this_is_not_the_command_name:-1: unmatched '
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> this is the bit I object to, the error message is OK.

Note: no `PATCH:' in the subject...

I was about to send/commit the patch below (which is kinda brute
force, setting scriptname to zsh when there is a -c option on the
command line).


But then I tried ksh and bash. ksh doesn't give me an error (?!?) and
bash does the same as zsh currently does.

I don't need to say that compatibility to bash doesn't interest me, do I?

So, should I commit the change?

Bye
 Sven

Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.1.1.51
diff -u -r1.1.1.51 init.c
--- Src/init.c	2000/03/23 04:22:57	1.1.1.51
+++ Src/init.c	2000/04/04 12:09:26
@@ -222,6 +222,7 @@
 		cmd = *argv;
 		opts[INTERACTIVE] &= 1;
 		opts[SHINSTDIN] = 0;
+		scriptname = ztrdup("zsh");
 	    } else if (**argv == 'o') {
 		if (!*++*argv)
 		    argv++;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Still problems with scriptname (presumably)

[Peter Stephenson]

Sven Wischnowsky wrote:
> Peter Stephenson wrote:
> > % zsh -c 'echo '\' this_is_not_the_command_name
> > this_is_not_the_command_name:-1: unmatched '
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > this is the bit I object to, the error message is OK.
> 
> But then I tried ksh and bash. ksh doesn't give me an error (?!?) and
> bash does the same as zsh currently does.

You're right, and in fact I've known about this for ages and mentioned it
before and was just thinking about it today and the penny still didn't
drop... Bourne shell derivatives when they use -c set $0 to the first
argument.  That needs to be kept.  There's no reason for an option which
will just add to the confusion.

I actually saw something like this somewhere else, where my $PS1 turned up
in an error message, and I can't remember where it was so I don't know if
that was a real bug.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Still problems with scriptname (presumably)

[Peter Stephenson]

% zsh -c 'echo '\' this_is_not_the_command_name
this_is_not_the_command_name:-1: unmatched '
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this is the bit I object to, the error message is OK.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk