More than you ever wanted to know about #
The first shell to use it as a comment was csh(1), Bill Joy did this.
This was also pre #! in the kernel so the shell had to exec scripts,
not the kernel. This had traditionally been done after the exec() failed
then shell ould run "sh argv[0]", but with two shells this was now a problem.
So csh would look at the first line of the script and if it was a #\n
it would exec csh on it if not it would exec sh(1) on it. This was check
was also placed into to BSD's (not v7 nor att's) bourne shell so it could
run csh scripts as well.
However this was not the first use of # as a comment character. That award
goes to Brian Kernighan's ratfor(1) (rational fortran) compiler in 1974-75.
Then Feldman used in make(1) in 1976, followed by Kernighan's m4(1), learn(1)
and most famously awk(1) in 1977
Bourne shell, written around 1976, eventualy picked this up later on but after
the initial v7 release. And as some noted the : was kind of a comment, it
was a command that did an exit(0) orginally for labels for Thompson's
shell's goto command. The : command was eventually hard linked to the
true(1) command
Remember # was hard to type on teletypes as that was the erase character, so
to enter it, you needed to type \#
(# as erase and @ as line kill came from multics btw)
It was so hard to type that the orignal assember based on DEC PAL-11R,
that addressing syntax changed @ to * and # to $.
In DEC it would be--
MOV @X, R0;
In UNIX asm it became --
mov *x, r0
So this is also why C pointers use * notation.
-Brian
> From: Dave Horsfall dave at horsfall.org
>
>On Sat, 4 Jan 2020, Chet Ramey 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.
>
>Yes, that's what I meant.
>
>> 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
Hoi,
in a computer forum I came across a very long command line,
including `xargs' and `sh -c'. Anyways, throughout the thread
it was modified several times, when accidently a pipe symbol
appeared between the command and the output redirection. The
command line did nothing; it ran successful. I was confused,
because I expected to see a syntax error in case of
``cmd|>file''. This made me wonder ...
With help of Sven Mascheck, I was able to clear my understanding.
The POSIX shell grammer provided the answer:
pipeline : pipe_sequence
...
pipe_sequence : command
| pipe_sequence '|' linebreak command
;
command : simple_command
...
simple_command : cmd_prefix cmd_word cmd_suffix
| cmd_prefix cmd_word
| cmd_prefix <--- HIER!
| cmd_name cmd_suffix
| cmd_name
;
cmd_prefix : io_redirect
...
io_redirect : io_file
...
io_file : '<' filename
| LESSAND filename
| '>' filename
...
A redirection is a (full) simple_command ... and because
``simple_command | simple_command'' is allowed, so is
``io_file | io_file''. This can lead to such strange (but
valid) command lines like:
<a | >b
>b | <a
Sven liked this one:
:|>:
Here some further fun variants:
:|:>:
<:|:>:
They would provide nice puzzles. ;-)
My understanding was helped most by detaching from the
semantics and focussing on syntax. This one is obviously
valid, no matter it has no effect:
:|:|:
From there it was easier to grasp:
>a | >a | >a
Which is valid, because ``>a'' is a (complete) simple_command.
Thus, no bug but consistent grammer. ;-)
If one would have liked to forbid such a corner case,
additional special case handling would have been necessary
... which is in contrast to the Unix way.
Sven checked the syntax against various shells with these
results:
- Syntax ok in these shells:
SVR2 sh (Ultrix), SVR4 sh (Heirloom)
ksh93
bash-1.05, bash-aktuell
pdksh-5.2.14
ash-0.4.26, dash-0.5.6.1
posh-0.3.7, posh-0.12.3
mksh-R24, mksh-R52b
yash-2.29
zsh-3.0.8, zsh-4.3.17
- Exception to the rule:
7thEd sh:
# pwd|>>file
# echo $?
141
On first sight ok, but with a silent error ... SIGPIPE (128+13).
I'd be interested in any stories and information around this
topic.
What about 7thEd sh?
meillo
> I was always sad that the development of C that became Alef never got off
> the ground.
It eventuated in Go, which is definitely aloft, and responds
to Mike Bianchi's specific desires. Go also has a library
ecosystem, which C does not.
With its clean parallelism, Go may be suitable for handling
the complexity of whole-paragraph typsetting in the face
of unexpected traps, line-length changes, etc.
Doug
I'm having a party on Saturday January 11 (and if any of you are in Tucson,
or want to come to Tucson for it, you're invited; email me for the address
and time).
Although the party is Elvis-themed, it's really about boardgaming and
classic videogaming.
So I kind of wanted to put a general-purpose Z-machine interpreter on my
PiDP-11, so that people could play Infocom (and community) games on a real
terminal.
Turns out there wasn't really one, so I ported the venerable ZIP (which I
have renamed "zterp" for obvious reasons) to 2.11BSD on the PDP-11, and I
also wrote a little utility I call "tmenu" to take a directory (and an
optional command applying to files in the directory) and make a numbered
menu, so that my guests who are not familiar with Actual Bourne Shell can
play games too.
These things are at:
https://github.com/athornton/pdp11-zterp
and
https://github.com/athornton/pdp11-tmenu/
Both are K&R C, and compile with the 2.11BSD system C compiler.
My biggest disappointment is that the memory map of Trinity, my favorite
Infocom game, is weird and even though it's only a V5 game, I can't
allocate enough memory to start it. Other than that, V5 and below seem to
work mostly fine; V8 is in theory supported but no game that I've tried has
little enough low memory that I can malloc() it using C on 2.11BSD.
Adam
I have always marveled at folks who can maintain multiple
versions of software, but Larry's dispatch from the
trenches reveals hurdles I hadn't imagined. Kudos for
keeping groff alive.
Speaking of which, many thanks to all who pitched in
on the %% nit that I reported. The instant response
compares rather favorably to an open case I've been
following in gcc, which was originally filed in 2002.
Doug
The use of %% to designate a literal % in printf is not
a recent convention. It was defined in K&R, first edition.
Doug
Ralph Cordery wrote:
Though that may seem odd to our modern C-standardised eyes, it's
understandable in that if it isn't a valid %f, etc., format specifier
then it's a literal percent sign.
According to K&R the behavior of % followed by something
unexpected is undefined. So the behavior of Ralph's example
is officially an accident. (It's uncharacteristic of Dennis
to have defined printf so that there was no guaranteed way
to get a literal % into a format.)
Doug
------------------------------------------------
Ralph Corderoy wrote:
$ printf '%s\n' \
.PS 'print sprintf("%.17g %.0f% % %%", 3.14, 42, 99)' .PE |
> pic >/dev/null
3.1400000000000001 42% % %%
Though that may seem odd to our modern C-standardised eyes, it's
understandable in that if it isn't a valid %f, etc., format specifier
then it's a literal percent sign.
The linux kernel never implemented support for a few features of obsolete
terminals. I find myself wanting to use Raspberry Pi-style linux machines
with old hardware, so this became quite frustrating.
So, I've put together a patch to the n_tty line discipline that adds some
things needed for using a Teletype model 33 or similar natively:
- XCASE, escaping uppercase (and a few special characters) for input and
display,
- CRDLY, delay to allow time for the carriage-return function;
- NLDLY, delay to allow time for the newline function.
With XCASE and ICANON, the terminal outputs a backslash before uppercase
characters; and accepts a backslash escape to set input to uppercase. The
usual way to use this is `stty lcase`, which also down-cases all input by
default. The special character escapes are:
\^ to ~
\! to |
\( to {
\) to }
\' to `
With CRDLY there are three options, CR0 through CR2; and with NLDLY there
are options NL0 (no delay) and NL1 (one delay). This patch uses fill
characters for delay, not timing, so these flags only take effect when
OFILL is also set.
Note: this doesn't change `agetty`, which I don't think implements
uppercase login detection right now. I have a Teletype running with
auto-login; and then `stty 110 icanon lcase ofill cr1 nl1`.
Code changes and some brief build instructions are here:
https://github.com/hughpyle/ASR33/tree/master/rpi/kernel
Compare with the raspberrypi tree, here,
https://github.com/raspberrypi/linux/compare/rpi-4.19.y...hughpyle:teletype
Not yet submitted upstream - the changes are in quite a high-traffic code
path, and also I just don't know how :) Feedback is very welcome!
-Hugh
All, I got a new printer with a better duplex scanner. I've just scanned
all the Unix Review magazines that I've got (1984-85 period) and uploaded
them to www.archive.org:
https://archive.org/search.php?query=title%3A%28Unix%20Review%29%20AND%20me…
Merry festive-season-of-your-choice,
Warren
P.S I have a bunch of Unix/World magazines, just waiting for a stronger
guillotine to arrive.
Computer History Museum curator Dag Spicer passed along a question from former CHM curator Alex Bochannek that I thought someone on this list might be able to answer. The paper "The M4 Macro Processor” by Kernighan and Ritchie says:
> The M4 macro processor is an extension of a macro processor called M3 which was written by D. M. Ritchie for the AP-3 minicomputer; M3 was in turn based on a macro processor implemented for [B. W. Kernighan and P. J. Plauger, Software Tools, Addison-Wesley, Inc., 1976].
Alex and Dag would like to learn more about this AP-3 minicomputer — can anyone help?
