Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
csh-style history expansion (!!/!*/!$/^) for Korn or POSIX shells?
92 views
Skip to first unread message
Axel Reichert
Feb 27, 2021, 6:02:23 AM2/27/21
to
Hello,
for some historic accident (I started with csh/tcsh) I am quite fond of
(at least) these four handy history expansions:
$ echo 1 2 3
1 2 3
$ echo !!
echo echo 1 2 3
echo 1 2 3
$ echo 1 2 3
1 2 3
$ echo !*
echo 1 2 3
1 2 3
$ echo 1 2 3
1 2 3
$ echo !$
echo 3
3
$ echo foo
foo
$ ^foo^bar
echo bar
bar
bash also has them, but Korn and POSIX shells are lacking these
features. Is there any easy workaround? From an .mkshrc file I got the
ideas
alias doch='sudo $(fc -ln -1)'
which covers the most frequent case of "sudo !!" and
alias r='fc -s'
which results in a slightly different syntax,
r foo=bar
instead of
^foo^bar
but that's fine.
!* and !$ seem to be more tricky, because they are typically not the
first word on the command line, and thus cannot be defined as an
alias. Shell functions have some naming restrictions, but even with
bd() { fc -ln -1 | awk '{print $NF}' ; }
after
echo 1 2 3
an
echo $(bd)
is necessary, as obviously
echo bd
will not do. Any ideas for something less clumsy?
Best regards
Axel
for some historic accident (I started with csh/tcsh) I am quite fond of
(at least) these four handy history expansions:
$ echo 1 2 3
1 2 3
$ echo !!
echo echo 1 2 3
echo 1 2 3
$ echo 1 2 3
1 2 3
$ echo !*
echo 1 2 3
1 2 3
$ echo 1 2 3
1 2 3
$ echo !$
echo 3
3
$ echo foo
foo
$ ^foo^bar
echo bar
bar
bash also has them, but Korn and POSIX shells are lacking these
features. Is there any easy workaround? From an .mkshrc file I got the
ideas
alias doch='sudo $(fc -ln -1)'
which covers the most frequent case of "sudo !!" and
alias r='fc -s'
which results in a slightly different syntax,
r foo=bar
instead of
^foo^bar
but that's fine.
!* and !$ seem to be more tricky, because they are typically not the
first word on the command line, and thus cannot be defined as an
alias. Shell functions have some naming restrictions, but even with
bd() { fc -ln -1 | awk '{print $NF}' ; }
after
echo 1 2 3
an
echo $(bd)
is necessary, as obviously
echo bd
will not do. Any ideas for something less clumsy?
Best regards
Axel
Janis Papanagnou
Feb 27, 2021, 10:43:52 AM2/27/21
to
!* is simply r
^x^y is r x=y
echo !$ is echo $_
(Note that 'r' is predefined in ksh, no need to define an alias.)
I have no code pattern for echo !! because I do that in the
history editor. In vi-mode for example
<cursor up> I echo <blank> <enter>
i.e. get last line, insert at the front the string echo, add the
blank.
HTH.
Janis
> Best regards
>
> Axel
>
Christian Weisgerber
Feb 27, 2021, 11:30:09 AM2/27/21
to
On 2021-02-27, Axel Reichert <ma...@axel-reichert.de> wrote:
> $ echo 1 2 3
> 1 2 3
> $ echo !$
> echo 3
> 3
echo $_
> $ echo 1 2 3
> 1 2 3
> $ echo !$
> echo 3
> 3
Hmm, this doesn't appear to be in POSIX. Anybody know a shell that
doesn't implement it?
> $ echo 1 2 3
> 1 2 3
> $ echo !*
> echo 1 2 3
> 1 2 3
arguments, what you actually want to do is replace the command, i.e.
% foo 1 2 3
% bar !*
But you can do that directly...
> $ echo foo
> foo
> $ ^foo^bar
> echo bar
> bar
command if it matches.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Janis Papanagnou
Feb 27, 2021, 11:37:20 AM2/27/21
to
On 27.02.2021 16:38, Christian Weisgerber wrote:
> On 2021-02-27, Axel Reichert <ma...@axel-reichert.de> wrote:
>
>> $ echo 1 2 3
>> 1 2 3
>> $ echo !$
>> echo 3
>> 3
>
> echo $_
>
> Hmm, this doesn't appear to be in POSIX. Anybody know a shell that
> doesn't implement it?
dash, posh, ...
> On 2021-02-27, Axel Reichert <ma...@axel-reichert.de> wrote:
>
>> $ echo 1 2 3
>> 1 2 3
>> $ echo !$
>> echo 3
>> 3
>
> echo $_
>
> Hmm, this doesn't appear to be in POSIX. Anybody know a shell that
> doesn't implement it?
sh (i.e. on my system, whatever that is, or whatever it is emulating)
It is supported by the prominent shells (ksh, bash, zsh).
Janis
Axel Reichert
Feb 27, 2021, 12:24:41 PM2/27/21
to
Janis Papanagnou <janis_pa...@hotmail.com> writes:
> !* is simply r
Hm, in mksh "r" reruns the complete last command. I was only interested
in re-using all arguments from the last command. But Christian (thanks!)
had the right idea:
foo 1 2 3
bar !*
is equivalent to
foo 1 2 3
^foo^bar
or
r foo=bar
> !$ is echo $_
Confirmed for mksh, but neither for bosh nor for yash.
> (Note that 'r' is predefined in ksh, no need to define an alias.)
Yes. At most a muscle memory issue to get used to it instead of ^.
> no code pattern for echo !!
The only use case that immediately comes to my mind is the sudo !!. And
this is covered by the "doch" alias in mksh, which I mentioned ("doch"
is a nice name for this from a German point of view, by the way).
In the mean time I have found something for !$ in yash (which allows for
aliases also for other words of the command line than the first. It is
called "global" alias, see
https://yash.osdn.jp/doc/syntax.html#aliases
and
https://yash.osdn.jp/doc/_alias.html
With this information I cobbled together
alias -g !%='$(fc -ln -2 -2 | awk "{print \$NF}")'
The name "!%" is the closest "neighbour" to "!$" on the keyboard, "$" is
forbidden in alias names. Now
mkdir foo bar baz
cd !%
changes to baz, as desired.
Thanks!
Axel
P. S.: In mksh, the history file access must be done with "fc -ln -1",
whereas yash apparently immediately writes the "current" command line to
the file (prior to alias expansion), so the second-to-last has to be
fetched. No idea what POSIX says about that.
> !* is simply r
Hm, in mksh "r" reruns the complete last command. I was only interested
in re-using all arguments from the last command. But Christian (thanks!)
had the right idea:
foo 1 2 3
bar !*
is equivalent to
foo 1 2 3
^foo^bar
or
r foo=bar
> !$ is echo $_
Confirmed for mksh, but neither for bosh nor for yash.
> (Note that 'r' is predefined in ksh, no need to define an alias.)
> no code pattern for echo !!
this is covered by the "doch" alias in mksh, which I mentioned ("doch"
is a nice name for this from a German point of view, by the way).
In the mean time I have found something for !$ in yash (which allows for
aliases also for other words of the command line than the first. It is
called "global" alias, see
https://yash.osdn.jp/doc/syntax.html#aliases
and
https://yash.osdn.jp/doc/_alias.html
With this information I cobbled together
alias -g !%='$(fc -ln -2 -2 | awk "{print \$NF}")'
The name "!%" is the closest "neighbour" to "!$" on the keyboard, "$" is
forbidden in alias names. Now
mkdir foo bar baz
cd !%
changes to baz, as desired.
Thanks!
Axel
P. S.: In mksh, the history file access must be done with "fc -ln -1",
whereas yash apparently immediately writes the "current" command line to
the file (prior to alias expansion), so the second-to-last has to be
fetched. No idea what POSIX says about that.
Janis Papanagnou
Feb 27, 2021, 1:29:58 PM2/27/21
to
On 27.02.2021 18:24, Axel Reichert wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> writes:
>
>> !* is simply r
>
> Hm, in mksh "r" reruns the complete last command. I was only interested
> in re-using all arguments from the last command. [...]
> Janis Papanagnou <janis_pa...@hotmail.com> writes:
>
>> !* is simply r
>
> Hm, in mksh "r" reruns the complete last command. I was only interested
Ah, I see. I saw that you used the same command and assumed you
just wanted a repetition.
Yes, Christian noted that replacement works also on the command.
Nonetheless I seem to prefer the built-in editor to replacement
in practical work (vi-mode in my case, other may prefer emacs).
In case of a change of the command where the arguments shall be
the same I also use the command history; for example to change
echo to print it's just
<cursor up> cw print
The fine thing with history editing is that you not only have that
predefined handful of special cases implemented but you have full
control. Given that you also don't need more key-strokes than with
the '!'-expansions I think it's worth trying to give up old habits.
(It's probably difficult to change long time fostered habits, but
it's possible. In the 1980's I also started with the csh, but never
missed any of its features.)
Janis
Axel Reichert
Feb 27, 2021, 2:14:38 PM2/27/21
to
Janis Papanagnou <janis_pa...@hotmail.com> writes:
> Christian noted that replacement works also on the command.
I knew this, but did not "see" it. Just used it to fix typos. Talking
> Christian noted that replacement works also on the command.
about old habits ... (-:
> The fine thing with history editing is that you not only have that
> predefined handful of special cases implemented but you have full
> control.
the command line (I tend to use tons of pipes). Of course, an
"instrument" flight in contrast to a "visual" flight can lead to
terrible mistakes.
> you also don't need more key-strokes than with the '!'-expansions
point.
Axel
Christian Weisgerber
Feb 27, 2021, 2:30:09 PM2/27/21
to
On 2021-02-27, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> echo $_
>>
>> Hmm, this doesn't appear to be in POSIX. Anybody know a shell that
>> doesn't implement it?
>
> dash, posh, ...
> sh (i.e. on my system, whatever that is, or whatever it is emulating)
It is supported by FreeBSD's sh(1), which is a POSIXified descendant
>> echo $_
>>
>> Hmm, this doesn't appear to be in POSIX. Anybody know a shell that
>> doesn't implement it?
>
> dash, posh, ...
> sh (i.e. on my system, whatever that is, or whatever it is emulating)
of the Almquist shell, and thus a relative of dash. And it's been
there since the initial 1991 import into what was to become 4.4BSD.
It _is_ implemented by dash on some Linux systems I just tried.
Janis Papanagnou
Feb 27, 2021, 8:50:10 PM2/27/21
to
On 27.02.2021 20:14, Axel Reichert wrote:
>[...]
Here, as already mentioned, we have (in all prominent shells) the
mkdir foobarbaz
cd $_
Interactively I use it all the time (and see no reason or advantage
of using '!$' that is not widely supported, specifically not in ksh
[the shell I use]).
Of course the $_ covers also only a special case, but in the zoo of
Unix commands it's helpful (for the example above, or in cases where
the last of many argument is special, for example a directory, as in
cp/mv args... dir).
The history editing is excellent for the cases that have partly been
mentioned already and that are also achievable with just two (or so)
keystrokes (changing the command, prepending another command), and
also for common cases like appending new arguments, or if one wants
to address changes not supported by other means like deleting or
changing existing options or inserting new options, or generally if
you have more complex changes.
In the ksh/vi editing mode that I use I sometimes also expand the
variable $_ (by '<Esc> *') to be able to change details of the args
if necessary. This makes it very flexible also for ad hoc editing
cases.
Janis
>[...]
>> you also don't need more key-strokes than with the '!'-expansions
>
> Depends. An "mkdir foobarbaz", "cd !$" is hard to beat.
For this it makes no sense to use command history editing, we agree.
>
> Depends. An "mkdir foobarbaz", "cd !$" is hard to beat.
Here, as already mentioned, we have (in all prominent shells) the
mkdir foobarbaz
cd $_
Interactively I use it all the time (and see no reason or advantage
of using '!$' that is not widely supported, specifically not in ksh
[the shell I use]).
Of course the $_ covers also only a special case, but in the zoo of
Unix commands it's helpful (for the example above, or in cases where
the last of many argument is special, for example a directory, as in
cp/mv args... dir).
The history editing is excellent for the cases that have partly been
mentioned already and that are also achievable with just two (or so)
keystrokes (changing the command, prepending another command), and
also for common cases like appending new arguments, or if one wants
to address changes not supported by other means like deleting or
changing existing options or inserting new options, or generally if
you have more complex changes.
In the ksh/vi editing mode that I use I sometimes also expand the
variable $_ (by '<Esc> *') to be able to change details of the args
if necessary. This makes it very flexible also for ad hoc editing
cases.
Janis
Eric Pozharski
Feb 28, 2021, 5:33:39 AM2/28/21
to
with <slrns3kps5...@lorvorc.mips.inka.de> Christian Weisgerber wrote:
> On 2021-02-27, Axel Reichert <ma...@axel-reichert.de> wrote:
*SKIP*
> On 2021-02-27, Axel Reichert <ma...@axel-reichert.de> wrote:
> What's the use case for this? Presumably if you want to repeat all
> arguments, what you actually want to do is replace the command, i.e.
>
> % foo 1 2 3
> % bar !*
$ ls -lXh ~/pig # should really functionize these too :(
> arguments, what you actually want to do is replace the command, i.e.
>
> % foo 1 2 3
> % bar !*
$ ls ~/pig/*{mp3,mp4} ~/pig/something-with-no-unique-suffix.tar.gz
$ .,m+cp !*
$ rm !* && .,iso.touch
> But you can do that directly...
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
Christian Weisgerber
Feb 28, 2021, 10:30:09 AM2/28/21
to
> Nonetheless I seem to prefer the built-in editor to replacement
> in practical work (vi-mode in my case, other may prefer emacs).
I think it's clear that the csh history facility pre-dates the
> in practical work (vi-mode in my case, other may prefer emacs).
widespread adoption of video terminals. People used this when
typing at their ASR-33s.
jo...@schily.net
Feb 28, 2021, 1:20:45 PM2/28/21
to
In article <slrns3nd9r...@lorvorc.mips.inka.de>,
1970s.
Around 1975, people did get 110 Baud modems at home and this was indeed the
reason to rename the shell builtin "chdir" into "cd".
In 1979, when csh started with it's strange history editing concept, I
designed and build a 300 Baud modem for my home and with 300 Baud, there
is no speed problem with history editing anymore. I was using this modem
with a DEC VT50a modem from 1974.
In 1982, I designed a modern integrated history editor and at that time, a
minimum transfer speed of 1200 Baud was common. Typically, 9600 Baud have been
used.
In 1984, when I integrated my history editing concept into a UNIX shell, it
turned out that a similar concept was available with VMS on VAX machines.
--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Christian Weisgerber <na...@mips.inka.de> wrote:
>On 2021-02-27, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>
>> Nonetheless I seem to prefer the built-in editor to replacement
>> in practical work (vi-mode in my case, other may prefer emacs).
>
>I think it's clear that the csh history facility pre-dates the
>widespread adoption of video terminals. People used this when
>typing at their ASR-33s.
This seems to be a missinterprtation of the technical constraints from the
>On 2021-02-27, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>
>> Nonetheless I seem to prefer the built-in editor to replacement
>> in practical work (vi-mode in my case, other may prefer emacs).
>
>I think it's clear that the csh history facility pre-dates the
>widespread adoption of video terminals. People used this when
>typing at their ASR-33s.
1970s.
Around 1975, people did get 110 Baud modems at home and this was indeed the
reason to rename the shell builtin "chdir" into "cd".
In 1979, when csh started with it's strange history editing concept, I
designed and build a 300 Baud modem for my home and with 300 Baud, there
is no speed problem with history editing anymore. I was using this modem
with a DEC VT50a modem from 1974.
In 1982, I designed a modern integrated history editor and at that time, a
minimum transfer speed of 1200 Baud was common. Typically, 9600 Baud have been
used.
In 1984, when I integrated my history editing concept into a UNIX shell, it
turned out that a similar concept was available with VMS on VAX machines.
--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Kenny McCormack
Feb 28, 2021, 3:15:29 PM2/28/21
to
In article <s1gmtp$6h8$1...@news.dns-netz.com>, <jo...@schily.net> wrote:
...
>In 1979, when csh started with it's strange history editing concept, I ...
>
>In 1982, I ...
>
>In 1984, when I ...
HNFY.
--
"Unattended children will be given an espresso and a free kitten."
...
>In 1979, when csh started with it's strange history editing concept, I ...
>
>In 1982, I ...
>
>In 1984, when I ...
HNFY.
--
"Unattended children will be given an espresso and a free kitten."
Keith Thompson
Feb 28, 2021, 5:42:50 PM2/28/21
to
jo...@schily.net writes:
> In article <slrns3nd9r...@lorvorc.mips.inka.de>,
> Christian Weisgerber <na...@mips.inka.de> wrote:
>>On 2021-02-27, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>
>>> Nonetheless I seem to prefer the built-in editor to replacement
>>> in practical work (vi-mode in my case, other may prefer emacs).
>>
>>I think it's clear that the csh history facility pre-dates the
>>widespread adoption of video terminals. People used this when
>>typing at their ASR-33s.
>
> This seems to be a missinterprtation of the technical constraints from the
> 1970s.
>
> Around 1975, people did get 110 Baud modems at home and this was indeed the
> reason to rename the shell builtin "chdir" into "cd".
My understand has always been that the motivation for abbreviating
> In article <slrns3nd9r...@lorvorc.mips.inka.de>,
> Christian Weisgerber <na...@mips.inka.de> wrote:
>>On 2021-02-27, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>
>>> Nonetheless I seem to prefer the built-in editor to replacement
>>> in practical work (vi-mode in my case, other may prefer emacs).
>>
>>I think it's clear that the csh history facility pre-dates the
>>widespread adoption of video terminals. People used this when
>>typing at their ASR-33s.
>
> This seems to be a missinterprtation of the technical constraints from the
> 1970s.
>
> Around 1975, people did get 110 Baud modems at home and this was indeed the
> reason to rename the shell builtin "chdir" into "cd".
"chdir" to "cd" (along with other agressively abbreviated commands like
"mv", "cp", etc.) was not the speed of output, but the speed of input.
Unix, as I understand it, was developed using keyboards that required
substantial force to press a key, and most work would have been done
using terminals directly connected to the computer, not remotely using
modems. I've never heard that slow modems were much of an influence on
the short command names.
This article (simply the first hit on a quick web search) supports that
impression: https://catonmat.net/why-unix-commands-are-short
Perhaps your experience was atypical?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Janis Papanagnou
Feb 28, 2021, 11:05:53 PM2/28/21
to
On 28.02.2021 23:42, Keith Thompson wrote:
in my fingers.)
> and most work would have been done
> using terminals directly connected to the computer, not remotely using
> modems. I've never heard that slow modems were much of an influence on
> the short command names.
This all makes sense.
> This article (simply the first hit on a quick web search) supports that
> impression: https://catonmat.net/why-unix-commands-are-short
>
> Perhaps your experience was atypical?
The other posters statements doesn't make sense. While voluminous
downstream data were an issue the short upstream commands certainly
not (even at the low transmission symbol rates at that time). I'm
not sure if his statement is (at "best") a myth or just made up.
Janis
> jo...@schily.net writes:
>>
>> Around 1975, people did get 110 Baud modems at home and this was indeed the
>> reason to rename the shell builtin "chdir" into "cd".
>
> My understand has always been that the motivation for abbreviating
> "chdir" to "cd" (along with other agressively abbreviated commands like
> "mv", "cp", etc.) was not the speed of output, but the speed of input.
> Unix, as I understand it, was developed using keyboards that required
> substantial force to press a key,
Indeed. (I still feel that resistance force of DEC's vt100 keys
>>
>> Around 1975, people did get 110 Baud modems at home and this was indeed the
>> reason to rename the shell builtin "chdir" into "cd".
>
> My understand has always been that the motivation for abbreviating
> "chdir" to "cd" (along with other agressively abbreviated commands like
> "mv", "cp", etc.) was not the speed of output, but the speed of input.
> Unix, as I understand it, was developed using keyboards that required
> substantial force to press a key,
in my fingers.)
> and most work would have been done
> using terminals directly connected to the computer, not remotely using
> modems. I've never heard that slow modems were much of an influence on
> the short command names.
> This article (simply the first hit on a quick web search) supports that
> impression: https://catonmat.net/why-unix-commands-are-short
>
> Perhaps your experience was atypical?
downstream data were an issue the short upstream commands certainly
not (even at the low transmission symbol rates at that time). I'm
not sure if his statement is (at "best") a myth or just made up.
Janis
Keith Thompson
Mar 1, 2021, 1:07:42 AM3/1/21
to
Janis Papanagnou <janis_pa...@hotmail.com> writes:
> On 28.02.2021 23:42, Keith Thompson wrote:
>> jo...@schily.net writes:
>>>
>>> Around 1975, people did get 110 Baud modems at home and this was
>>> indeed the reason to rename the shell builtin "chdir" into "cd".
>>
>> My understand has always been that the motivation for abbreviating
>> "chdir" to "cd" (along with other agressively abbreviated commands like
>> "mv", "cp", etc.) was not the speed of output, but the speed of input.
>> Unix, as I understand it, was developed using keyboards that required
>> substantial force to press a key,
>
> Indeed. (I still feel that resistance force of DEC's vt100 keys
> in my fingers.)
I've used VT100s. I was thinking of ASR33 teletypes. I've never
> On 28.02.2021 23:42, Keith Thompson wrote:
>> jo...@schily.net writes:
>>>
>>> Around 1975, people did get 110 Baud modems at home and this was
>>> indeed the reason to rename the shell builtin "chdir" into "cd".
>>
>> My understand has always been that the motivation for abbreviating
>> "chdir" to "cd" (along with other agressively abbreviated commands like
>> "mv", "cp", etc.) was not the speed of output, but the speed of input.
>> Unix, as I understand it, was developed using keyboards that required
>> substantial force to press a key,
>
> Indeed. (I still feel that resistance force of DEC's vt100 keys
> in my fingers.)
used an ASR33, but I understand they were much stiffer than VT100s.
At 110 Baud, or about 10 characters per second, it could probably
keep up well with a typical user's typing speed, especially if input
is buffered. Without buffering some characters might be lost in
faster bursts, but again, that doesn't seem to be the reason for
Unix's short command names.
Digressing a bit, even with modern equipment the short command names
don't seem to be any more difficult to use once you get used to them.
A friend once asked me why Unix wasn't modified to use clearer names
(remove for rm, copy for cp, etc.) I pointed out that it would be
almost trivial to do exactly that by defining a set of aliases -- and
the fact that nobody bothers to do that should tell you something.
("Nobody" may have been a slight exaggeration.)
>> and most work would have been done
>> using terminals directly connected to the computer, not remotely using
>> modems. I've never heard that slow modems were much of an influence on
>> the short command names.
>
> This all makes sense.
>
>> This article (simply the first hit on a quick web search) supports that
>> impression: https://catonmat.net/why-unix-commands-are-short
>>
>> Perhaps your experience was atypical?
>
> The other posters statements doesn't make sense. While voluminous
> downstream data were an issue the short upstream commands certainly
> not (even at the low transmission symbol rates at that time). I'm
> not sure if his statement is (at "best") a myth or just made up.
Janis Papanagnou
Mar 1, 2021, 2:54:18 AM3/1/21
to
On 01.03.2021 07:07, Keith Thompson wrote:
>
> I've used VT100s. I was thinking of ASR33 teletypes. I've never
> used an ASR33, but I understand they were much stiffer than VT100s.
Hmm, okay. If even the vt100 had been a pain I don't want to think
>
> I've used VT100s. I was thinking of ASR33 teletypes. I've never
> used an ASR33, but I understand they were much stiffer than VT100s.
about even worse keyboards.
> At 110 Baud, or about 10 characters per second, it could probably
> keep up well with a typical user's typing speed, especially if input
> is buffered. Without buffering some characters might be lost in
> faster bursts, but again, that doesn't seem to be the reason for
> Unix's short command names.
>
> Digressing a bit, even with modern equipment the short command names
> don't seem to be any more difficult to use once you get used to them.
> A friend once asked me why Unix wasn't modified to use clearer names
> (remove for rm, copy for cp, etc.) I pointed out that it would be
> almost trivial to do exactly that by defining a set of aliases -- and
> the fact that nobody bothers to do that should tell you something.
> ("Nobody" may have been a slight exaggeration.)
time had short commands. For example a mainframe from my (and also
the other poster's) domain was the Telefunken system called TR 440,
with a 48 bit processor. The command language was very verbose,
spelling out words like 'UEBERSETZE' and files like 'QUELLE=...'
(meaning "compile" and "source" respectively), though abbreviations
were also possible (IIRC; I cannot find the command manual at the
moment). But we had no keyboards with terminals at that time, all
input was created offline using Hollerith/IBM punch-cards that we
created on a separate hardware (with not so bad keyboards, compared
to the DEC vt100 that I later used). Also terminal access, e.g. to
some Siemens computer (I think it was basically an IBM machine with
hardware from Japan) that I used later had longer commands than the
ones used by the Unix systems. The short Unix forms were exceptional
it seems, but the hardware and communication infrastructure were the
same, so it's hard to believe that it matters WRT limited bandwidth.
Janis
Janis Papanagnou
Mar 1, 2021, 7:17:15 AM3/1/21
to
On 01.03.2021 07:07, Keith Thompson wrote:
>
>
> At 110 Baud, or about 10 characters per second, it could probably
> keep up well with a typical user's typing speed, [...]
On first quick reading I missed that, but want to ask whether that
isn't a very very, erm.., "conservative" estimate. The unit Baud is
symbol/sec where symbol is not a bit, and a character needs not 8 bit.
When I was confronted with Baud decades ago I had got the impression
that it's a unit on signaling level, so (besides the above mentioned
facts) it's also depending on the modulation of the signal over the
channel. Maybe someone familiar with communications engineering can
shed some light on that.
Janis
jo...@schily.net
Mar 1, 2021, 7:41:24 AM3/1/21
to
In article <87eegzj...@nosuchdomain.example.com>,
So it actually may be less.
>keep up well with a typical user's typing speed, especially if input
>is buffered. Without buffering some characters might be lost in
>faster bursts, but again, that doesn't seem to be the reason for
>Unix's short command names.
This works as long as you are tying and like to see the echo.
If you like to use the up-arrow key from a modern history editor, this is too
slow.
An average line length is more than 10 characters.
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>At 110 Baud, or about 10 characters per second, it could probably
One startbit, 7 data bits, one parity and one stopbit gives 10 chars/s.
>At 110 Baud, or about 10 characters per second, it could probably
So it actually may be less.
>keep up well with a typical user's typing speed, especially if input
>is buffered. Without buffering some characters might be lost in
>faster bursts, but again, that doesn't seem to be the reason for
>Unix's short command names.
If you like to use the up-arrow key from a modern history editor, this is too
slow.
An average line length is more than 10 characters.
Randal L. Schwartz
Mar 1, 2021, 11:03:12 AM3/1/21
to
>>>>> "Keith" == Keith Thompson <Keith.S.T...@gmail.com> writes:
Keith> I've used VT100s. I was thinking of ASR33 teletypes. I've never
Keith> used an ASR33, but I understand they were much stiffer than
Keith> VT100s.
Keith> At 110 Baud, or about 10 characters per second, it could probably
Keith> keep up well with a typical user's typing speed, especially if
Keith> input is buffered. Without buffering some characters might be
Keith> lost in faster bursts, but again, that doesn't seem to be the
Keith> reason for Unix's short command names.
I spent junior high and highschool using an ASR-33 playing with HP2000
timeshare BASIC. Before school, morning break, lunch, and after school
every day. They were in rooms barely big enough to be called coat
closets, and I'm not surprised a lot of my hearing is gone today.
There was some physical interlock on the keyboard. You couldn't press a
key more often than a spinning device would get to top of the cycle.
You could hold down a "repeat" key, which wouldn't push the key back up
as soon as it was "sent", but instead send that key out as quick as the
spinning thing would cycle back around.
And yes, my fingers have more muscles than most of the rest of me. :)
It was years before I saw a terminal that ran at 300 baud, or had
lowercase.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig
Keith> I've used VT100s. I was thinking of ASR33 teletypes. I've never
Keith> used an ASR33, but I understand they were much stiffer than
Keith> VT100s.
Keith> At 110 Baud, or about 10 characters per second, it could probably
Keith> keep up well with a typical user's typing speed, especially if
Keith> input is buffered. Without buffering some characters might be
Keith> lost in faster bursts, but again, that doesn't seem to be the
Keith> reason for Unix's short command names.
I spent junior high and highschool using an ASR-33 playing with HP2000
timeshare BASIC. Before school, morning break, lunch, and after school
every day. They were in rooms barely big enough to be called coat
closets, and I'm not surprised a lot of my hearing is gone today.
There was some physical interlock on the keyboard. You couldn't press a
key more often than a spinning device would get to top of the cycle.
You could hold down a "repeat" key, which wouldn't push the key back up
as soon as it was "sent", but instead send that key out as quick as the
spinning thing would cycle back around.
And yes, my fingers have more muscles than most of the rest of me. :)
It was years before I saw a terminal that ran at 300 baud, or had
lowercase.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig
Christian Weisgerber
Mar 1, 2021, 11:30:10 AM3/1/21
to
On 2021-03-01, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> At 110 Baud, or about 10 characters per second, it could probably
>> keep up well with a typical user's typing speed, [...]
>
> On first quick reading I missed that, but want to ask whether that
> isn't a very very, erm.., "conservative" estimate. The unit Baud is
> symbol/sec where symbol is not a bit, and a character needs not 8 bit.
> When I was confronted with Baud decades ago I had got the impression
> that it's a unit on signaling level, so (besides the above mentioned
> facts) it's also depending on the modulation of the signal over the
> channel.
That is correct. However, in the earliest dial-up modems and for
>> At 110 Baud, or about 10 characters per second, it could probably
>> keep up well with a typical user's typing speed, [...]
>
> On first quick reading I missed that, but want to ask whether that
> isn't a very very, erm.., "conservative" estimate. The unit Baud is
> symbol/sec where symbol is not a bit, and a character needs not 8 bit.
> When I was confronted with Baud decades ago I had got the impression
> that it's a unit on signaling level, so (besides the above mentioned
> facts) it's also depending on the modulation of the signal over the
> channel.
EIA-232 serial ports, one symbol carries one bit. From there on,
people kept (ab)using "baud" in the sense of "bits per second".
Unless you're taking a deep dive into modem technology, it is a
reasonable assumption that people actually mean "bit/s" when they
say "baud".
Those "110 baud" modems may have been Bell 101, but more likely
their successor the Bell 103. The Bell 103 used frequency-shift
keying at up to 300 bd. As far as I know it was fully asynchronous
device whose symbol rate was controled by the terminal, i.e., you
could run it an arbitrary speed up to 300 bd.
Subsequent modem standards, starting with Bell 212A (US) and V.22
(international), switched to phase-shift keying and ran at a fixed
clock rate. That's also when the symbol rate (600 bd) and bit rate
(1200 bps) began to diverge.
Kaz Kylheku
Mar 1, 2021, 12:15:35 PM3/1/21
to
On 2021-03-01, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 28.02.2021 23:42, Keith Thompson wrote:
>> jo...@schily.net writes:
>>>
>>> Around 1975, people did get 110 Baud modems at home and this was indeed the
>>> reason to rename the shell builtin "chdir" into "cd".
>>
>> My understand has always been that the motivation for abbreviating
>> "chdir" to "cd" (along with other agressively abbreviated commands like
>> "mv", "cp", etc.) was not the speed of output, but the speed of input.
>> Unix, as I understand it, was developed using keyboards that required
>> substantial force to press a key,
>
> Indeed. (I still feel that resistance force of DEC's vt100 keys
> in my fingers.)
I did most of my hacking on an Apple II+ keyboard as a teen. At
>> jo...@schily.net writes:
>>>
>>> Around 1975, people did get 110 Baud modems at home and this was indeed the
>>> reason to rename the shell builtin "chdir" into "cd".
>>
>> My understand has always been that the motivation for abbreviating
>> "chdir" to "cd" (along with other agressively abbreviated commands like
>> "mv", "cp", etc.) was not the speed of output, but the speed of input.
>> Unix, as I understand it, was developed using keyboards that required
>> substantial force to press a key,
>
> Indeed. (I still feel that resistance force of DEC's vt100 keys
> in my fingers.)
university, suddenly my fingers were faced with the flimsy keyboards
of Apollo Domain Series workstations. Between that, and the abuse I
was heaping on my wrists by using 45 lb dumbbells, I developed a nasty
case of carpal tunnel syndrome.
The sports med clinic at the university prescribed Naproxen (which
was not yet over the counter). That helped with the symptoms, but
didn't solve the problem.
I recognized that the issue was that I was simply hammering very
hard on terribly light keys with short travel times. I could as well
have been drumming my fingers all day on a wooden chopping block.
I knew I needed a keyboard with stiff springs and long travel
times to properly absorb the energy of my pounding fingers.
I found that in the form of a DEC VT100 that was available in one
computer science student society room. I started working on that,
and the problem went away.
Headline: "DEC VT100 cures carpal tunnel".
--
TXR Programming Language: http://nongnu.org/txr
Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal
Keith Thompson
Mar 1, 2021, 5:54:00 PM3/1/21
to
1 bit per symbol, and that they required more than 8 bits for
each 8-bit byte (start bits, stop bits, etc.). I don't remember
the details, and I never used anything that slow. In any case,
10 characters per second probably isn't too far off.
Martijn Dekker
Mar 4, 2021, 10:32:43 AM3/4/21
to
On 2021-02-27 11:02:17 +0000, Axel Reichert said:
> bash also has them, but Korn and POSIX shells are lacking these
> features.
The Korn shell (i.e.: AT&T ksh93) has that feature, actually. Note that
> bash also has them, but Korn and POSIX shells are lacking these
> features.
mksh is not the Korn shell (as in David Korn's shell); it's a
derivative of pdksh which is an independently developed open-source
clone of an old closed-source generation of the Korn shell (ksh88).
Though mksh does add a few ksh93 features, and some mksh-specific ones.
Personally, I hate history expansion and turn it off, because it tends
to get in the way whenever you need an exclamation point for some other
purpose within double quotes, as in:
$ echo $BASH_VERSION; set -o histexpand
5.1.0(30)-rc2
$ echo "one!two"
bash: !two: event not found
$ echo "one\!two"
one\!two
$ echo $KSH_VERSION; set -o histexpand
Version AJM 93u+m/1.0.0-alpha+b48e5b33 2021-03-04
$ echo "one!two"
arch/darwin.i386-64/bin/ksh: !two": event not found
$ echo "one\!two"
one\!two
The command line is not added to the history so you can't arrow-up to
add the backslash necessary to work around this breakage; you have to
start from scratch. Way to defeat the purpose of the whole thing.
And even adding a backslash doesn't actually help, because the
backslash may escape the '!' but is still not removed itself. You're
expected to take the '!' out of the double-quoted string and use
another quoting mechanism for it.
So this breaks basic shell grammar. Double-quoted strings should not be
assigning special meaning to the '!'.
Hmm. Interestingly, zsh seems to act in a more consistent manner. If
you escape the '!' within double quotes, it does remove the escaping
backslash. So at least double-quoted strings only change from the
expected standard and don't become irreparably broken.
$ echo $ZSH_VERSION; set -o histexpand
5.8.0.2-dev
$ echo "one!two"
zsh: event not found: two
$ echo "one\!two"
one!two
Maybe I should change ksh 93u+m to act like zsh in this.
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
jo...@schily.net
Mar 4, 2021, 2:15:13 PM3/4/21
to
In article <iaccsn...@mid.individual.net>,
When I stopped using csh around 1985, I was glad to see that there no longer
was a need for quoting the csh history expansion special characters.
Martijn Dekker <mar...@inlv.demon.nl> wrote:
>The Korn shell (i.e.: AT&T ksh93) has that feature, actually. Note that
>mksh is not the Korn shell (as in David Korn's shell); it's a
>derivative of pdksh which is an independently developed open-source
>clone of an old closed-source generation of the Korn shell (ksh88).
>Though mksh does add a few ksh93 features, and some mksh-specific ones.
>
>Personally, I hate history expansion and turn it off, because it tends
>to get in the way whenever you need an exclamation point for some other
>purpose within double quotes, as in:
Thank you for sharing that impression, it is aligned with my impressions.
>The Korn shell (i.e.: AT&T ksh93) has that feature, actually. Note that
>mksh is not the Korn shell (as in David Korn's shell); it's a
>derivative of pdksh which is an independently developed open-source
>clone of an old closed-source generation of the Korn shell (ksh88).
>Though mksh does add a few ksh93 features, and some mksh-specific ones.
>
>Personally, I hate history expansion and turn it off, because it tends
>to get in the way whenever you need an exclamation point for some other
>purpose within double quotes, as in:
When I stopped using csh around 1985, I was glad to see that there no longer
was a need for quoting the csh history expansion special characters.
0 new messages