[TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[Nemo]

On 15/07/2018, Warren Toomey <wkt@tuhs.org> wrote (in part):
> Also:
> https://www.youtube.com/watch?v=NTfOnGZUZDk
>
> Where GREP Came From - Computerphile (with Brian Kernighan)

I was intrigued by BMK's comment that "ed" was never spokend as "ed"
by "those in the know", which leads me to wonder how things were
spoken.  Here is a litte list of how I pronounce things [with others'
versions in brackets].  Others will no doubt be aghast.

ls - "list" sometimes "l s";
rm - "remove";
chmod - "change mode" [but I have heard "ch-mode"]
ar - "archive" [others have said "arrr"]

N.

Re: [TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[arnold]

Nemo <cym224@gmail.com> wrote:

> I was intrigued by BMK's comment that "ed" was never spokend as "ed"
> by "those in the know", which leads me to wonder how things were
> spoken.

I always spelled out the two-letter commands: e-d, a-r, l-s, r-m, c-p.
chmod I pronounced as ch-mod (not mode), but 'rmdir' was 'remove dir'
and for some reason, mv was move. (I think the doc for vi officially
stated that the proram's name was to be pronounced v-i and not 'vie'.)

Undoubtedly there were many regional differences... :-)

Arnold

Re: [TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Interesting that of all the commands mentioned, ar is (at least for me) no
longer used (although I haven't used ed in many years). As I recall it, ar
was mostly of use to address the extremely low limits on inodes and disk
space: the former by packing a bunch of files/inodes into a single file,
the latter by saving the wasted space on any file that wasn't a multiple of
512 bytes. I guess it lives on in the creation of "libraries" that could be
loaded by compilers, although I think shared objects have largely replaced
archive files, and I'm not sure if archive files are even accepted any more.

On Tue, Jul 17, 2018 at 9:20 AM, <arnold@skeeve.com> wrote:

> Nemo <cym224@gmail.com> wrote:
>
> > I was intrigued by BMK's comment that "ed" was never spokend as "ed"
> > by "those in the know", which leads me to wonder how things were
> > spoken.
>
> I always spelled out the two-letter commands: e-d, a-r, l-s, r-m, c-p.
> chmod I pronounced as ch-mod (not mode), but 'rmdir' was 'remove dir'
> and for some reason, mv was move. (I think the doc for vi officially
> stated that the proram's name was to be pronounced v-i and not 'vie'.)
>
> Undoubtedly there were many regional differences... :-)
>
> Arnold
>

[-- Attachment #2: Type: text/html, Size: 1768 bytes --]

Re: [TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[arnold]

"John P. Linderman" <jpl.jpl@gmail.com> wrote:

> I guess it [ar] lives on in the creation of "libraries" that could be
> loaded by compilers, although I think shared objects have largely replaced
> archive files, and I'm not sure if archive files are even accepted any more.

Archive files (static libraries) are alive and well and work just fine,
on Linux and every other *nix that I know about. The format is even
used on Windows for static libraries and for whatever you call them when
linking dynamic libraries (they provide the symbols, but not the dll).
(Do a    file xxx.lib   on a Linux system with a .lib file from Windows
and you'll see. Boy was I surprised the first time I did that!)

Arnold

[TUHS] ar libraries [was: Speaking commands [Was: Bell System Technical Journal archive]]

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

On Wednesday, 18 July 2018 at 11:39:30 -0600, arnold@skeeve.com wrote:
> "John P. Linderman" <jpl.jpl@gmail.com> wrote:
>
>> I guess it [ar] lives on in the creation of "libraries" that could be
>> loaded by compilers, although I think shared objects have largely replaced
>> archive files, and I'm not sure if archive files are even accepted any more.
>
> Archive files (static libraries) are alive and well and work just fine,
> on Linux and every other *nix that I know about. The format is even
> used on Windows for static libraries and for whatever you call them when
> linking dynamic libraries (they provide the symbols, but not the dll).

This has been the case for FreeBSD too for as long as I can recall.  I
thought it was the case for all .a libraries.

  $ uname -a
  FreeBSD eureka.lemis.com 10.2-STABLE FreeBSD 10.2-STABLE #2 r290972: Wed Nov 25 11:38:38 AEDT 2015     grog@stable.lemis.com:/usr/obj/eureka/home/src/FreeBSD/svn/10/sys/GENERIC  amd64
  $ file /usr/lib/libc.a
  /usr/lib/libc.a: current ar archive

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] ar libraries [was: Speaking commands [Was: Bell System Technical Journal archive]]

[Paul Winalski]

>On Wednesday, 18 July 2018 at 11:39:30 -0600, arnold@skeeve.com wrote:
>
> Archive files (static libraries) are alive and well and work just fine,
> on Linux and every other *nix that I know about. The format is even
> used on Windows for static libraries and for whatever you call them when
> linking dynamic libraries (they provide the symbols, but not the dll).

The symbol index for archives of object (.o) files was initially
optional and created by a separate program called ranlib.  At some
point ranlib seems to have been integrated into ar.  When did this
happen?

The version of ranlib from the mid-1980s had an implementation that
was a bit too simple-minded.  It indexed all symbols with N_EXT set
and a non-zero n_value field.  This means that Fortran common blocks
and C uninitialized file-scope variables ended up in the ranlib index
of the archive, which is wrong--such symbols should not trigger an
object file to be loaded.  ranlib should have filtered out symbols
that have N_UNDF set as well as N_EXT.  ld had a faulty work-around
for this problem.  When a symbol in a ranlib index triggered the
loading of a module, and ld found that the symbol was in fact a common
symbol, ld said "oops" and unloaded the module.  But by this time ld
had already maximized the sizes of all common symbols, and that didn't
get backed out.  The result is that common symbols were allocated
space in .bss based on the largest size that ld saw while scanning
archives, NOT the largest size actually participating in the link.

There was in fact a bug in stdio that relied on this (mis-)feature.
It drove me bonkers when I ported the VMS linker to Ultrix.

-Paul W.

Re: [TUHS] ar libraries [was: Speaking commands [Was: Bell System Technical Journal archive]]

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

A few long-dormant brain cells woke up and convinced me that ranlib was
done by Peter Weinberger. Perhaps Doug or Peter can confirm or refute the
memory.

On Thu, Jul 19, 2018 at 11:29 AM, Paul Winalski <paul.winalski@gmail.com>
wrote:

> >On Wednesday, 18 July 2018 at 11:39:30 -0600, arnold@skeeve.com wrote:
> >
> > Archive files (static libraries) are alive and well and work just fine,
> > on Linux and every other *nix that I know about. The format is even
> > used on Windows for static libraries and for whatever you call them when
> > linking dynamic libraries (they provide the symbols, but not the dll).
>
> The symbol index for archives of object (.o) files was initially
> optional and created by a separate program called ranlib.  At some
> point ranlib seems to have been integrated into ar.  When did this
> happen?
>
> The version of ranlib from the mid-1980s had an implementation that
> was a bit too simple-minded.  It indexed all symbols with N_EXT set
> and a non-zero n_value field.  This means that Fortran common blocks
> and C uninitialized file-scope variables ended up in the ranlib index
> of the archive, which is wrong--such symbols should not trigger an
> object file to be loaded.  ranlib should have filtered out symbols
> that have N_UNDF set as well as N_EXT.  ld had a faulty work-around
> for this problem.  When a symbol in a ranlib index triggered the
> loading of a module, and ld found that the symbol was in fact a common
> symbol, ld said "oops" and unloaded the module.  But by this time ld
> had already maximized the sizes of all common symbols, and that didn't
> get backed out.  The result is that common symbols were allocated
> space in .bss based on the largest size that ld saw while scanning
> archives, NOT the largest size actually participating in the link.
>
> There was in fact a bug in stdio that relied on this (mis-)feature.
> It drove me bonkers when I ported the VMS linker to Ultrix.
>
> -Paul W.
>

[-- Attachment #2: Type: text/html, Size: 2538 bytes --]

Re: [TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[Kurt H Maier]

On Tue, Jul 17, 2018 at 10:39:20AM -0400, John P. Linderman wrote:
> Interesting that of all the commands mentioned, ar is (at least for
me) no
> longer used (although I haven't used ed in many years). 
        
".deb" packages (used by Debian and Ubuntu linuxes) are a header file   
and two .tar.gz files packed into ar format.  ar(1) is widely used to   
unscrew Debian packages on systems without dpkg tools installed.  So,
while it might not be be doing the same job, it retains some currency
in the land of linux.
        
khm

Re: [TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[Ron Natalie]

There was a quote going around where when asked if he would do anything differently, he said he’d put an e on the end of creat.   I guess he was tire of people calling it Cree-at.  

Sent from my iPhone

> On Jul 17, 2018, at 8:20 AM, arnold@skeeve.com wrote:
> 
> Nemo <cym224@gmail.com> wrote:
> 
>> I was intrigued by BMK's comment that "ed" was never spokend as "ed"
>> by "those in the know", which leads me to wonder how things were
>> spoken.
> 
> I always spelled out the two-letter commands: e-d, a-r, l-s, r-m, c-p.
> chmod I pronounced as ch-mod (not mode), but 'rmdir' was 'remove dir'
> and for some reason, mv was move. (I think the doc for vi officially
> stated that the proram's name was to be pronounced v-i and not 'vie'.)
> 
> Undoubtedly there were many regional differences... :-)
> 
> Arnold

Re: [TUHS] Speaking commands [Was: Bell System Technical Journal archive]

[arnold]

That was Ken Thompson who said that. And indeed, in Plan 9 it's called
"create".

Arnold

Ron Natalie <ron@ronnatalie.com> wrote:

> There was a quote going around where when asked if he would do anything differently, he said he’d put an e on the end of creat.   I guess he was tire of people calling it Cree-at.  
>
> Sent from my iPhone
>
> > On Jul 17, 2018, at 8:20 AM, arnold@skeeve.com wrote:
> > 
> > Nemo <cym224@gmail.com> wrote:
> > 
> >> I was intrigued by BMK's comment that "ed" was never spokend as "ed"
> >> by "those in the know", which leads me to wonder how things were
> >> spoken.
> > 
> > I always spelled out the two-letter commands: e-d, a-r, l-s, r-m, c-p.
> > chmod I pronounced as ch-mod (not mode), but 'rmdir' was 'remove dir'
> > and for some reason, mv was move. (I think the doc for vi officially
> > stated that the proram's name was to be pronounced v-i and not 'vie'.)
> > 
> > Undoubtedly there were many regional differences... :-)
> > 
> > Arnold
>