recent -s patch

recent -s patch

[Scott Schwartz]

I don't think -s should imply -i, as the patch does.  If I want both
I can type both.   

Is -s going to be standard, or will most people decline to apply the
patch?

Re: recent -s patch

[John Mackin]

    From: Scott Schwartz <schwartz@groucho.cs.psu.edu>

    I don't think -s should imply -i, as the patch does.  If I want both
    I can type both.   

    Is -s going to be standard, or will most people decline to apply the
    patch?

Scott and all,

I don't have a lot of time now, and have more mail to write yet, so
please forgive me if I am a little terse.

The point of -s is not `how should it work', but rather `how -must-
it work'.  No one wants to add -s to rc just because they think
it's a good idea.  They want (in some cases, need) to add -s to rc
_in order to be compatible with the de-facto standard for command
line arguments to UNIX shells_.  That's the point.  This is how
the -s argument works in sh and csh, and therefore, if rc is to
have a -s argument at all, this is how it MUST work in rc.

Personally, I have no need for -s and don't care whether it is
in or out: but if it is to be in, I insist that it work just as
it does in other shells.  Equally, rc cannot define new semantics
for -c or -e, etc.  I hope that's clear.

OK,
John.

Re: recent -s patch

[Scott Schwartz]

| Personally, I have no need for -s and don't care whether it is
| in or out: but if it is to be in, I insist that it work just as
| it does in other shells.  

Yes, I quite agree.  I didn't mention it before, but in csh and sh -s
does not imply -i.  The current patch for rc does the wrong thing.

Re: recent -s patch

[John Mackin]

Scott is quite right.  Just goes to show how little I've ever understood
that damned -s option anyway.  Someone who cares about it should fix the
patch so that -s doesn't imply -i.  Hey, can anyone on the list tell us
all if they have any reason at all for wanting -s?  Inquiring minds
want to know.  So far, we have Rich's reason, which is that -s is
passed to the invoked shell by `the OSF/1 script command'.  Any
other takers?

To put it another way, can anyone show me any real use for -s?  That
is, why is the damned idea good?  Try as I might I can't see any.
(This shouldn't be construed as an argument for keeping it out of
rc.  To the contrary, I will always be willing to entertain rc features
that keep it compatible (in appropriate ways) with traditional shells.)

OK,
John.

Re: recent -s patch

[Bob Gibson]

| Hey, can anyone on the list tell us
| all if they have any reason at all for wanting -s?  Inquiring minds
| want to know.  So far, we have Rich's reason, which is that -s is
| passed to the invoked shell by `the OSF/1 script command'.  Any
| other takers?

My editor, jove, starts up subshells with the -s option, and obviously
fails to do so if the shell doesn't support it.  In this case, the
correct thing to do would be to fix jove to make this configurable.
But if others have a need to add -s to rc, it would save me a bit of
work.  I realize this is a pretty lame reason for adding a new feature
so I won't try to defend it.  Then again, you now have two applications
which rely on the shell supporting -s.  I wonder how many more exist.

Re: recent -s patch

[David J. Fiander]

>From:  	Bob Gibson <rjg@sco.com>
>| Hey, can anyone on the list tell us
>| all if they have any reason at all for wanting -s?  Inquiring minds
>| want to know.  So far, we have Rich's reason, which is that -s is
>| passed to the invoked shell by `the OSF/1 script command'.  Any
>| other takers?
>
>My editor, jove, starts up subshells with the -s option, and obviously
>fails to do so if the shell doesn't support it.  In this case, the
>correct thing to do would be to fix jove to make this configurable.

The reason that jove does this is because is starts the shell
with either its command line arguments or the file names
associated with its buffers as arguments to the shell.  That
is, is says

	$SHELL -s file1 file2 file3

This way you can easily refer to the files you are editting in
your subshell.

It would be nice if this feature was documented, though.

- David