* Re: recent -s patch
@ 1992-06-29 1:36 Bob Gibson
1992-06-29 23:19 ` David J. Fiander
0 siblings, 1 reply; 6+ messages in thread
From: Bob Gibson @ 1992-06-29 1:36 UTC (permalink / raw)
To: John Mackin; +Cc: The rc Mailing List
| 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: recent -s patch
1992-06-29 1:36 recent -s patch Bob Gibson
@ 1992-06-29 23:19 ` David J. Fiander
0 siblings, 0 replies; 6+ messages in thread
From: David J. Fiander @ 1992-06-29 23:19 UTC (permalink / raw)
To: Bob Gibson; +Cc: The rc Mailing List
>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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: recent -s patch
1992-06-28 20:34 ` Scott Schwartz
@ 1992-06-28 21:01 ` John Mackin
0 siblings, 0 replies; 6+ messages in thread
From: John Mackin @ 1992-06-28 21:01 UTC (permalink / raw)
To: The rc Mailing List
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: recent -s patch
1992-06-28 19:47 ` John Mackin
@ 1992-06-28 20:34 ` Scott Schwartz
1992-06-28 21:01 ` John Mackin
0 siblings, 1 reply; 6+ messages in thread
From: Scott Schwartz @ 1992-06-28 20:34 UTC (permalink / raw)
To: John Mackin; +Cc: The rc Mailing List
| 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: recent -s patch
1992-06-26 4:11 Scott Schwartz
@ 1992-06-28 19:47 ` John Mackin
1992-06-28 20:34 ` Scott Schwartz
0 siblings, 1 reply; 6+ messages in thread
From: John Mackin @ 1992-06-28 19:47 UTC (permalink / raw)
To: The rc Mailing List
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* recent -s patch
@ 1992-06-26 4:11 Scott Schwartz
1992-06-28 19:47 ` John Mackin
0 siblings, 1 reply; 6+ messages in thread
From: Scott Schwartz @ 1992-06-26 4:11 UTC (permalink / raw)
To: rc
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1992-06-29 23:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1992-06-29 1:36 recent -s patch Bob Gibson
1992-06-29 23:19 ` David J. Fiander
-- strict thread matches above, loose matches on Subject: below --
1992-06-26 4:11 Scott Schwartz
1992-06-28 19:47 ` John Mackin
1992-06-28 20:34 ` Scott Schwartz
1992-06-28 21:01 ` John Mackin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).