4 Jan
2020
4 Jan
'20
2:58 a.m.
I'm interested in the possible motivations for a
redirection to be
a simple command.
I use it to truncate a file to zero length.
Or to create (an empty) file.
Doug
4 Jan
4 Jan
10:07 a.m.
New subject: sh: cmd | >file
Hoi.
[2020-01-03 21:58] Doug McIlroy <doug(a)cs.dartmouth.edu>
Thanks for the replies.
My question was not about the use cases for ``>file'' but *why*
it was made a simple command. Let me explain:
One creates an empty file or truncates a file with:
I'm interested in the possible motivations
for a redirection to be
a simple command.
I use it to truncate a file to zero length.
Or to create (an empty) file. file
why not with:
:>file
?
To me it looks to be the more sensible ... more regular way.
IO redirections for the shell itself could be made with:
exec >file 5>&
no matter if ``>file'' is a simple command or not. Because of
``exec'' the line is valid syntax (although the grammer probably
was retro-fitted), and the manpages (mksh, bash, heirloom sh) all
document exec without a command as a separate case (and the code
probably handles it as a separate case as well), thus nothing is
gained here from making ``>file'' a simple command.
This is what wonder about: Why make ``>file'' a simple command,
when -- as far as I can currently see -- there is no reason to do
so, as all uses could have been achieved in more regular ways as
well?
So, was it rather by accident and it settled or is there something
I don't see yet? Came `:' later in development, for instance, or
was it special in a way that it couldn't be used to create and
truncate files? Or is there even some clever design that I haven't
understood yet? Are there use cases that can only be achieved with
``>file'' but not with ``:>file''?
meillo
11:47 a.m.
New subject: sh: cmd | >file
Good morning!
On Sat, Jan 04, 2020 at 11:07:18AM +0100, markus schnalke wrote:
One creates an empty file or truncates a file with:
I think the key reason is that the shell does not build an AST from
the command you type, instead executing the phrases it encounters as it
sees them. So when the shell sees ">file", it opens "file" for
writing
in preparation of the rest of the command. If no command comes, the
line is handled the same way as an empty one and the redirections are
discarded. The shell could print an error here, but avoiding the side
effect of opening "file" for lines just consisting of redirects would be
difficult. But then, why should it print an error? The behaviour is
not harmful after all and I'd say that nobody really thought about this
being a thing when the shell was originally written.
Yours,
Robert Clausecker
--
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments
file
why not with:
:>file
?
To me it looks to be the more sensible ... more regular way.
IO redirections for the shell itself could be made with:
exec >file 5>&
no matter if ``>file'' is a simple command or not. Because of
``exec'' the line is valid syntax (although the grammer probably
was retro-fitted), and the manpages (mksh, bash, heirloom sh) all
document exec without a command as a separate case (and the code
probably handles it as a separate case as well), thus nothing is
gained here from making ``>file'' a simple command.
This is what wonder about: Why make ``>file'' a simple command,
when -- as far as I can currently see -- there is no reason to do
so, as all uses could have been achieved in more regular ways as
well? 
10:31 p.m.
New subject: sh: cmd | >file
On 1/4/20 6:47 AM, Robert Clausecker wrote:
> This is what wonder about: Why make
``>file'' a simple command,
> when -- as far as I can currently see -- there is no reason to do
> so, as all uses could have been achieved in more regular ways as
> well?
I'm going to answer in terms of the Bourne shell and its successors.
I think the key reason is that the shell does not
build an AST from
the command you type, instead executing the phrases it encounters as it
sees them.
This is false.
So when the shell sees ">file", it opens
"file" for writing
in preparation of the rest of the command.
Also not correct, at least if you mean opening it before completing the
parse.
If no command comes, the
line is handled the same way as an empty one and the redirections are
discarded.
Not really. The shell parses the line into a list of words. Those words
make up a simple command, since none of the words were identified as a
reserved word, and so are not the first word of a compound command. It's
the default case, basically.
The POSIX standard gives a pretty good summary of what happens next:
the redirections get separated out and the rest of the words are
expanded.
You already have to deal with the expansions returning nothing, since the
words could all be null variable expansions, so the case where there are
no words besides redirections and assignment statements isn't that much
different.
The shell could print an error here,
It could, but Bourne chose not to.
but avoiding the side
effect of opening "file" for lines just consisting of redirects would be
difficult. But then, why should it print an error? The behaviour is
not harmful after all
This is true. There aren't any other cases where the shell makes a null
expansion an error without being directly asked, so it would not have
made sense to make a command consisting entirely of words that expand to
null an error. There's no good reason to treat a null command differently
from that case.
and I'd say that nobody really thought about
this
being a thing when the shell was originally written.
On the contrary, I think Bourne made a conscious choice to handle
redirections `separately' from simple command expansion and execution, and
a conscious choice to continue to process redirections (in a subshell, as
if the shell had forked to execute a non-builtin) when word expansion
resulted in no words.
It's the `exec' case with redirections that I think was the special case,
since Bourne's (v7) shell didn't allow redirections with builtins at all.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
9:02 p.m.
New subject: sh: cmd | >file
On Sat, 4 Jan 2020, markus schnalke wrote:
My question was not about the use cases for
``>file'' but *why* it was
made a simple command. Let me explain:
One creates an empty file or truncates a file with:
The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an actual
internal Shell command) when "" (the null command) will do the job?
I guess only the Bell Labs bods here can answer this.
-- Dave
file
why not with:
:>file
?
To me it looks to be the more sensible ... more regular way. 
9:06 p.m.
New subject: sh: cmd | >file
Dave Horsfall writes:
On Sat, 4 Jan 2020, markus schnalke wrote:
Don't know if Steve Bourne is on this list, but he's been a great source
of information when I've had questions about why the shell did things the
way it did.
Jon
My question was not about the use cases for
``>file'' but *why* it was
made a simple command. Let me explain:
One creates an empty file or truncates a file with:
The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an actual
internal Shell command) when "" (the null command) will do the job?
I guess only the Bell Labs bods here can answer this.
-- Dave file
why not with:
:>file
?
To me it looks to be the more sensible ... more regular way. 
5 Jan
5 Jan
12:03 a.m.
New subject: sh: cmd | >file
I contacted Steve --- he is on the list, and says he'll weigh in.
eric
On 2020-01-04 13:06, Jon Steinhart wrote:
Dave Horsfall writes:
On Sat, 4 Jan 2020, markus schnalke wrote:
Don't know if Steve Bourne is on this list, but he's been a great source
of information when I've had questions about why the shell did things the
way it did.
Jon
My question was not about the use cases for
``>file'' but *why* it was
made a simple command. Let me explain:
One creates an empty file or truncates a file with:
The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an actual
internal Shell command) when "" (the null command) will do the job?
I guess only the Bell Labs bods here can answer this.
-- Dave file
why not with:
:>file
?
To me it looks to be the more sensible ... more regular way. 
1:49 a.m.
New subject: sh: cmd | >file
v7 Bourne shell does not appear to treat '#' as a comment.
I've built termlib and curses for v7 and am now trying to find a small
screen editor. I was trying se, but the version I have ships as a shell
archive, and it doesn't actually unpack on v7, in part because of the
comments.
v7 is a target in Jove's Ovmakefile, so that's what I'm trying now.
Slow-pasting uuencoded files into the terminal is gross, but efficacious....
Adam
On Sat, Jan 4, 2020 at 5:48 PM Eric Allman <tuhs(a)eric.allman.name> wrote:
I contacted Steve --- he is on the list, and says
he'll weigh in.
eric
On 2020-01-04 13:06, Jon Steinhart wrote:
Dave Horsfall writes:
> On Sat, 4 Jan 2020, markus schnalke wrote:
>
>> My question was not about the use cases for ``>file'' but *why* it
was
>> made a simple command. Let me explain:
>>
>> One creates an empty file or truncates a file with:
>>
>> >file
>>
>> why not with:
>>
>> :>file
>> ?
>>
>> To me it looks to be the more sensible ... more regular way.
>
> The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an
actual
internal
Shell command) when "" (the null command) will do the job?
I guess only the Bell Labs bods here can answer this.
-- Dave
Don't know if Steve Bourne is on this list, but he's been a great source
of information when I've had questions about why the shell did things the
way it did.
Jon
2:44 a.m.
New subject: sh: cmd | >file
On 1/4/20 8:49 PM, Adam Thornton wrote:
v7 Bourne shell does not appear to treat '#'
as a comment.
It does, when the shell is not interactive and reading input from a script,
pipe, or input redirection.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
8:15 a.m.
New subject: sh: cmd | >file
V7 indeed did not have "#" as a comment. Programs use the ":" command
for that, and was careful of what was in the comment. The ":" command was called
SYSNULL in the source.
Later versions of Steve's shell had COMCHAR defined to be a "#" and
tested for that symbol in word(), eating up all the characters until it got to a newline.
The version of Seventh Edition I used to carry around and embed in things had that mod. My
original Seventh did not.
On Jan 4, 2020, at 9:44 PM, Chet Ramey
<chet.ramey(a)case.edu> wrote:
On 1/4/20 8:49 PM, Adam Thornton wrote:
v7 Bourne shell does not appear to treat
'#' as a comment.
It does, when the shell is not interactive and reading input from a script,
pipe, or input redirection.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
3:16 p.m.
New subject: sh: cmd | >file
On 1/5/20 3:15 AM, Brantley Coile wrote:
V7 indeed did not have "#" as a comment.
Programs use the ":" command for that, and was careful of what was in the
comment. The ":" command was called SYSNULL in the source.
Later versions of Steve's shell had COMCHAR defined to be a "#" and
tested for that symbol in word(), eating up all the characters until it got to a newline.
The version of Seventh Edition I used to carry around and embed in things had that mod. My
original Seventh did not.
I think the 7th edition shell I have must have those changes, since it
definitely understands `#' comments.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
4 Jan
4 Jan
9:11 p.m.
New subject: sh: cmd | >file
On Sun, 5 Jan 2020, Dave Horsfall wrote:
The Unix philosophy, perhaps i.e. keep it simple? Why
have ":" (an
actual internal Shell command) when "" (the null command) will do the
job?
Also, remember that ":" was also used as a comment, before "#" was
used.
-- Dave
9:39 p.m.
New subject: sh: cmd | >file
On Sat, Jan 4, 2020, 3:11 PM Dave Horsfall <dave(a)horsfall.org> wrote:
On Sun, 5 Jan 2020, Dave Horsfall wrote:
I thought it was a null label for a goto target... :)
Warner
-- Dave
The Unix philosophy, perhaps i.e. keep it simple?
Why have ":" (an
actual internal Shell command) when "" (the null command) will do the
job?
Also, remember that ":" was also used as a comment, before "#" was
used.
10:19 p.m.
New subject: sh: cmd | >file
Was : actually designed for commenting? If so, at what point did it become
a command that always returns zero exit status? Was it always built-in, or
did it originally have a separate filesystem existence (like "[")? Python
has a useful "pass" command, but : is much nicer because you can
"comment"
out a single command in (e.g.) an if/then and it remains syntactically
valid and executable. I find it very elegant.
Terry
On Sat, Jan 4, 2020 at 10:40 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Sat, Jan 4, 2020, 3:11 PM Dave Horsfall <dave(a)horsfall.org> wrote:
On Sun, 5 Jan 2020, Dave Horsfall wrote:
I thought it was a null label for a goto target... :)
Warner
-- Dave
The Unix philosophy, perhaps i.e. keep it simple?
Why have ":" (an
actual internal Shell command) when "" (the null command) will do the
job?
Also, remember that ":" was also used as a comment, before "#" was
used.
10:33 p.m.
New subject: sh: cmd | >file
On 1/4/20 5:19 PM, Terry Jones wrote:
Was : actually designed for commenting? If so, at
what point did it become
a command that always returns zero exit status? Was it always built-in, or
did it originally have a separate filesystem existence (like "[")? Python
has a useful "pass" command, but : is much nicer because you can
"comment"
out a single command in (e.g.) an if/then and it remains syntactically
valid and executable. I find it very elegant.
It's elegant until you forget that `:' continues to process redirections.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
11:53 p.m.
New subject: sh: cmd | >file
On Sat, 4 Jan 2020, Chet Ramey wrote:
It's elegant until you forget that `:'
continues to process redirections.
So just keep remembering that it's an actual command :-)
Which reminds me: which Shell introduced "#" as a true comment?
Hmmm, not quite true; only the C-Shell says "#: Command not found" so it
only works in a script; odd...
Then again, no-one in their right mind uses "csh" :-)
-- Dave
5 Jan
5 Jan
12:04 a.m.
New subject: sh: cmd | >file
On Sun, Jan 05, 2020 at 10:53:47AM +1100, Dave Horsfall wrote:
On Sat, 4 Jan 2020, Chet Ramey wrote:
In bash (turning off interactive_comments):
$ shopt -u interactive_comments
$ echo hello # world
hello # world
$ # oh
bash: #: command not found
In zsh (by default):
$ echo hello # world
hello # world
$ # oh
zsh: command not found: #
zsh is the fun one though (allows setting the comment character):
$ histchars[3]='@'
$ echo hello @ world
hello @ world
$ setopt INTERACTIVE_COMMENTS
$ echo hello @ world
hello
$ @ oh, a comment
$
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
It's elegant until you forget that `:'
continues to process redirections.
So just keep remembering that it's an actual command :-)
Which reminds me: which Shell introduced "#" as a true comment?
Hmmm, not quite true; only the C-Shell says "#: Command not found" so it
only works in a script; odd...
Then again, no-one in their right mind uses "csh" :-)
-- Dave
2:41 a.m.
New subject: sh: cmd | >file
On 1/4/20 6:53 PM, Dave Horsfall wrote:
On Sat, 4 Jan 2020, Chet Ramey wrote:
Define "true comment." The v7 shell had `#' as the comment character, but
it only worked when in non-interactive shells. I think it was the Sys III
shell that made it work when the shell was interactive.
This is, incidentally, why bash has the `interactive_comments' option,
which I saw in another message. BSD, which most of the GNU developers were
using at the (pre-POSIX) time, used the v7 shell and didn't have
interactive comments. When a sufficiently-advanced POSIX draft required
them, we added it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
It's elegant until you forget that `:'
continues to process redirections.
So just keep remembering that it's an actual command :-)
Which reminds me: which Shell introduced "#" as a true comment? 
1:45 p.m.
New subject: sh: cmd | >file
On Sat, Jan 04, 2020 at 09:41:59PM -0500, Chet Ramey wrote:
concerning "interactive" I think instead of the V7 sh you rather have
the BSD sh in mind here.
V7 sh didn't know # at all. At ATT it came with SysIII (both modes).
And keep in mind, stty erase defaulted to # on V7, even until SySV (and 3BSD),
and this character wouldn't have been handy anyway. 4+BSD changed this.
4.1BSD implemented #, and 4.3 BSD changed it to "non-interactive only".
(And all this is not to be confused with the # hack to exec to csh on 3+BSD,
only if it's the first character in a script.)
BTW, an academic yet funny example of : side effects is this
: `echo output 1>&2`
Sven
On 1/4/20 6:53 PM, Dave Horsfall wrote:
Which reminds
me: which Shell introduced "#" as a true comment?
Define "true comment." The v7 shell had `#' as the comment character, but
it only worked when in non-interactive shells. I think it was the Sys III
shell that made it work when the shell was interactive.
This is, incidentally, why bash has the `interactive_comments' option,
which I saw in another message. BSD, which most of the GNU developers were
using at the (pre-POSIX) time, used the v7 shell and didn't have
interactive comments. When a sufficiently-advanced POSIX draft required
them, we added it.
3:18 p.m.
New subject: sh: cmd | >file
On 1/5/20 8:45 AM, Sven Mascheck via TUHS wrote:
4.1BSD implemented #, and 4.3 BSD changed it to
"non-interactive only".
Yes, 4.3 (or SunOS) is what most of us were using at the time.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
9:21 p.m.
New subject: sh: cmd | >file
On Sat, 4 Jan 2020, Chet Ramey wrote:
Yes, that's what I meant.
Which reminds
me: which Shell introduced "#" as a true comment?
Define "true comment." The v7 shell had `#' as the comment character, but
it only worked when in non-interactive shells. I think it was the Sys III
shell that made it work when the shell was interactive. This is, incidentally, why bash has the
`interactive_comments' option,
which I saw in another message. BSD, which most of the GNU developers were
using at the (pre-POSIX) time, used the v7 shell and didn't have
interactive comments. When a sufficiently-advanced POSIX draft required
them, we added it.
I never did catch up with all the options on the various shells; I just
stick with the defaults in general. Eg:
aneurin% man bash | wc -l
5947
Life's too short...
-- Dave
6 Jan
6 Jan
1:53 p.m.
New subject: sh: cmd | >file
On 1/5/20 4:21 PM, Dave Horsfall wrote:
On Sat, 4 Jan 2020, Chet Ramey wrote:
Yes, that's what I meant.
It was the Sys III shell; I have a v7 shell that's apparently not the
original.
Which
reminds me: which Shell introduced "#" as a true comment?
Define "true comment." The v7 shell had `#' as the comment character, but
it only worked when in non-interactive shells. I think it was the Sys III
shell that made it work when the shell was interactive. I never did catch up with all the options on the
various shells; I just
stick with the defaults in general. Eg:
aneurin% man bash | wc -l
5947
$ wc -l doc/bash.0
6206 doc/bash.0
I still get reports that things are not documented in sufficient detail.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
3:42 p.m.
New subject: sh: cmd | >file
Seems the man page for bash is longer than Steve's original source:
ehg% pwd
/sys/editions/unix/7e/usr/src/cmd/sh
ehg% wc -l *.[ch] | tail -1
4111 total
On Jan 6, 2020, at 8:53 AM, Chet Ramey
<chet.ramey(a)case.edu> wrote:
On 1/5/20 4:21 PM, Dave Horsfall wrote:
On Sat, 4 Jan 2020, Chet Ramey wrote:
Yes, that's what I
meant.
It was the Sys III shell; I have a v7 shell that's apparently not the
original.
Which
reminds me: which Shell introduced "#" as a true comment?
Define "true comment." The v7 shell had `#' as the comment character, but
it only worked when in non-interactive shells. I think it was the Sys III
shell that made it work when the shell was interactive. I never did catch up with all the options on the
various shells; I just
stick with the defaults in general. Eg:
aneurin% man bash | wc -l
5947
$ wc -l doc/bash.0
6206 doc/bash.0
I still get reports that things are not documented in sufficient detail.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/ 
3:46 p.m.
New subject: sh: cmd | >file
Brantley Coile <brantley(a)coraid.com> wrote:
Seems the man page for bash is longer than
Steve's original source:
ehg% pwd
/sys/editions/unix/7e/usr/src/cmd/sh
ehg% wc -l *.[ch] | tail -1
4111 total
And Bash (40 years later) does correspondingly more than the V7 shell did.
I think these comparisons are a red herring.
Would anyone who uses Bash regularly, both interactively and
for scripting, really want to go back to using the V7 sh
for production work?
I certainly would not.
Arnold
4:13 p.m.
New subject: sh: cmd | >file
On Mon, Jan 6, 2020 at 10:46 AM <arnold(a)skeeve.com> wrote:
Would anyone who uses Bash regularly, both interactively and for
scripting, really want to go back to using the V7 sh
for production work? I certainly would not.
A heretic!! Believers all know '*Bourne to Program, Type with Joy'
*and*
'One true bracing style' *are the two most important commandments of UNIX
programmer!
Seriously, I still write my scripts as v7 and use (t)csh as my login shell
on all my UNIX boxes ;-)
Clem
8:44 p.m.
New subject: sh: cmd | >file
Clem Cole <clemc(a)ccc.com> wrote:
On Mon, Jan 6, 2020 at 10:46 AM
<arnold(a)skeeve.com> wrote:
Time to move into the 21st century. Tcsh has been obsolete for decades.
Myself, when first exposed to the csh, I revolted (and was revolted) and
stuck with the Bourne shell, even though there was no job control or
history.
I later ported Ron Minnich's job control from the BRL S5R2 on top of BSD shell
to the plain BSD shell and also wrote my own !-style history editor for
it. (Both were posted on USENET in the early 80s.)
After that I got ksh86 and later ksh88, with vi-style command line
editing and never looked back. Then, in the early 90s when I no longer
had ksh access, I switched to bash, contributed fixes to readline's vi
mode, and have been with bash since.
(For a while I tried rc + readline, but that just didn't do it for me.
Bash all the way. Zsh is too different in its vi mode.)
And kudos to Chet for dealing with all the POSIX zigzags ("clarifications",
"definitions") for the shell over the decades. I admire him, but I
don't envy him.
My two cents,
Arnold
Would anyone who uses Bash regularly, both
interactively and for
scripting, really want to go back to using the V7 sh
for production work? I certainly would not.
A heretic!! Believers all know '*Bourne to Program, Type with Joy' *and*
'One true bracing style' *are the two most important commandments of UNIX
programmer!
Seriously, I still write my scripts as v7 and use (t)csh as my login shell
on all my UNIX boxes ;-) 
8:51 p.m.
New subject: sh: cmd | >file
On Mon, 6 Jan 2020, arnold(a)skeeve.com wrote:
After that I got ksh86 and later ksh88, with vi-style
command line
editing and never looked back. Then, in the early 90s when I no longer
had ksh access, I switched to bash, contributed fixes to readline's vi
mode, and have been with bash since.
I dig ksh93, because it's lighter and faster than bash, but I wish its tab
completion worked like bash's.
-uso.
9:39 p.m.
New subject: sh: cmd | >file
Clem Cole <clemc(a)ccc.com> writes:
On Mon, Jan 6, 2020 at 3:44 PM
<arnold(a)skeeve.com> wrote
I am glad that I am not alone ... I tend to write older style sh
scripts and try to use tcsh as an interactive shell when I can. BTW -
tcsh is still being updated ...
--
Brad Spencer - brad(a)anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Time to move into the 21st century. Tcsh has been obsolete for decades.
Burned into the ROMs in my fingers :-)
9:29 p.m.
New subject: sh: cmd | >file
On Mon, 6 Jan 2020, arnold(a)skeeve.com wrote:
Would anyone who uses Bash regularly, both
interactively and
for scripting, really want to go back to using the V7 sh
for production work?
I have never used all the fancy stuff in BASH such as the arithmetic
functions; I still use "expr" etc for portability.
My favourite shell is still ZSH (the alternative was CSH, and my views on
that POS are well known) because I started using it long before BASH, and
even then I use a fraction of its power. I did dabble with KSH, though (I
needed command editing and history).
-- Dave
9:55 p.m.
New subject: sh: cmd | >file
On 1/6/20 4:29 PM, Dave Horsfall wrote:
On Mon, 6 Jan 2020, arnold(a)skeeve.com wrote:
Portability to what? The POSIX $((...)) arithmetic expansion is widely
implemented and near-universally available.
Some of the other things are more esoteric, but you should be able to
increase your expectation to POSIX features and still be sufficiently
portable.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
Would anyone who uses Bash regularly, both
interactively and
for scripting, really want to go back to using the V7 sh
for production work?
I have never used all the fancy stuff in BASH such as the arithmetic
functions; I still use "expr" etc for portability.
10:22 p.m.
New subject: sh: cmd | >file
On Mon, 6 Jan 2020, Chet Ramey wrote:
As I said, I never bothered to learn "$((...))" because "expr" works
just
fine. And I might come across an old machine at some time; I come from
the school of "Make it work before making it pretty" and I extend that to
backwards compatibility.
And "expr" is burned into my brain :-)
I have never
used all the fancy stuff in BASH such as the arithmetic
functions; I still use "expr" etc for portability.
Portability to what? The POSIX $((...)) arithmetic expansion is widely
implemented and near-universally available. Some of the other things are more esoteric, but you
should be able to
increase your expectation to POSIX features and still be sufficiently
portable.
I might get around to it, but at 67 I may not have much time (or
incentive)... Besides, programming is only a hobby for me, as I'm long
retired.
-- Dave
10:52 p.m.
New subject: sh: cmd | >file
On Mon, Jan 6, 2020 at 4:56 PM Chet Ramey <chet.ramey(a)case.edu> wrote:
On 1/6/20 4:29 PM, Dave Horsfall wrote:
Huh.
I've been in this "use the old stuff for portability" camp for some time,
but now that you mention it....I can't think of any systems I use that
require resorting to old-style shell-isms.
What an interesting epiphany. It reminds me of the time when first I
realized that continuing to write K&R-style C was no longer necessary, as
everything that I used had an ANSI-compatible compiler and supported
function prototypes.
Seeing backticks in the rearview mirror is a welcome change.
- Dan C.
On Mon, 6 Jan 2020, arnold(a)skeeve.com wrote:
Portability to what? The POSIX $((...)) arithmetic expansion is widely
implemented and near-universally available.
Some of the other things are more esoteric, but you should be able to
increase your expectation to POSIX features and still be sufficiently
portable.
Would anyone who uses Bash regularly, both
interactively and
for scripting, really want to go back to using the V7 sh
for production work?
I have never used all the fancy stuff in BASH such as the arithmetic
functions; I still use "expr" etc for portability.
7 Jan
7 Jan
12:50 a.m.
New subject: sh: cmd | >file
On Jan 6, 2020, at 2:55 PM, Chet Ramey
<chet.ramey(a)case.edu> wrote:
On 1/6/20 4:29 PM, Dave Horsfall wrote:
Portability to v7, of course!
I mean, I’m joking, but also not.
I felt like v7 might be enough of a daily driver that I could port some fun stuff to it,
but…damn, even ex/vi 3.x is huge, jove will take a lot of work, and I can’t find a
minimalist screen editor in K&R C. The best I’ve managed is TE but although there is
presumably a Unix port, I couldn’t find it. Porting termcap and curses was easy, but….the
whole reason I want them, initially, is so that I don’t have to use ed. If anyone knows
of a small screen editor that will build easily on v7 I want to know about it.
This is in contrast to 2.11BSD, where, yeah, it’s just Unix, and especially with a TCP/IP
stack, is completely usable. The PDP-11’s 64K address space is constraining and (as it
turned out) influences the way I write programs—for my menu front end for ZIP, I started
with my usual technique of making a struct with all the fields I’d want for my menu
structure, and a linked list of those things, but that turned out to be a hog and a simple
**char plus some utility functions to index the elements ended up being completely
adequate.
Adam
On Mon, 6 Jan 2020, arnold(a)skeeve.com wrote:
Portability to what? The POSIX $((...)) arithmetic expansion is widely
implemented and near-universally available.
Some of the other things are more esoteric, but you should be able to
increase your expectation to POSIX features and still be sufficiently
portable.
Would anyone who uses Bash regularly, both
interactively and
for scripting, really want to go back to using the V7 sh
for production work?
I have never used all the fancy stuff in BASH such as the
arithmetic
functions; I still use "expr" etc for portability. 
6 Jan
6 Jan
10:10 p.m.
New subject: sh: cmd | >file
On Tue, 07 Jan 2020 08:29:30 +1100 Dave Horsfall <dave(a)horsfall.org> wrote:
On Mon, 6 Jan 2020, arnold(a)skeeve.com wrote:
csh was more convenient as an interactive shell but it was not
good for writing scripts & I always used /bin/sh for scripts.
I switched from csh to zsh almost since the time it was first
posted to alt.sources - over 29 years ago!
Would anyone who uses Bash regularly, both
interactively and
for scripting, really want to go back to using the V7 sh
for production work?
I have never used all the fancy stuff in BASH such as the arithmetic
functions; I still use "expr" etc for portability.
My favourite shell is still ZSH (the alternative was CSH, and my views on
that POS are well known) because I started using it long before BASH, and
even then I use a fraction of its power. I did dabble with KSH, though (I
needed command editing and history).
4 Jan
4 Jan
10:44 p.m.
New subject: sh: cmd | >file
Hoi.
[2020-01-04 23:19] Terry Jones <terry(a)jon.es>
Was : actually designed for commenting?
Hardly, because who would want comments to have side effects:
: don't do this
Or this:
: ignored; echo executed
Or this dangerously ``outcommented'' line:
: test ... && rm file
!
Using : for comments is only possible as the command does nothing
and ignores its arguments ... but the shell parses the arguments
as for every other command ... and executes stuff in the line that
are no arguments to :.
In case of #, the rest of the line is truly ignored, as comments
should be like.
but : is much nicer because you can
"comment" out a
single command in (e.g.) an if/then and it remains syntactically valid and
executable. I find it very elegant.
Can you please give an example for me to understand what you mean
by that?
meillo
11:01 p.m.
New subject: sh: cmd | >file
On Sat, Jan 4, 2020 at 11:45 PM markus schnalke <meillo(a)marmaro.de> wrote:
While developing, I frequently have some code like:
if test -f somefile
then
cmd1
cmd2
else
echo somefile is missing
fi
I have the "else" clause because I initially want to explicitly see some
output in that case. A bit later if I temporarily don't want the output
(but want to keep the else and the echo line around) I can just put a colon
before the echo. You can't do that with a # because you get a syntax error.
And if you wanted to use # you'd then have to put in some other do-nothing
line (maybe a : by itself) to keep valid syntax. In a situation like this
I will eventually end up deleting the echo line and the preceding else, but
during development I like being able to use : in this way.
Terry
but : is much nicer because you can
"comment" out a
single command in (e.g.) an if/then and it remains syntactically valid
and
executable. I find it very elegant.
Can you please give an example for me to understand what you mean
by that?
meillo
10:22 p.m.
New subject: sh: cmd | >file
On Sat, 4 Jan 2020, Warner Losh wrote:
Also, remember that ":" was also used
as a comment, before "#"
was used.
I thought it was a null label for a goto target... :)
Yes, I'd forgotten that... The Shell, although simple in concept, was
really quite powerful if you knew how to use it.
-- Dave
1565
days inactive
1568
days old
37 comments
19 participants
participants (19)
-
Adam Thornton -
Andreas Kusalananda Kähäri -
arnold＠skeeve.com -
Bakul Shah -
Brad Spencer -
Brantley Coile -
Chet Ramey -
Clem Cole -
Dan Cross -
Dave Horsfall -
Doug McIlroy -
Eric Allman -
Jon Steinhart -
markus schnalke -
Robert Clausecker -
Steve Nickolas -
Sven Mascheck -
Terry Jones -
Warner Losh