TUHS

tuhs@tuhs.org

6464 discussions

The Unix shell: a 50-year view -- feedback wanted

by Jon Steinhart

I not only found this paper offensive, but was more offended that ACM would publish something like this and give it an award to boot. I'm planning to send the authors and ACM what's below. Would appreciate any feedback that you could provide to make it better. Thanks, Jon I read your "Unix Shell Programming: The Next 50 Years" expecting some well thought out wisdom from learned experiences. I was sorely disappointed. o The paper never defines what is meant by the term "Unix shell." … [View More] I think that you're using to mean a command interpreter as described in the POSIX 1003.2 documents. o There is no 50 year old Unix shell. I started using Unix in the early 1970s, and the command interpreter at the time (Ken Thompson's shell) was nothing like later shells such as the Bourne shell (sh since research V7 Unix), Korn shell (ksh), C shell (csh), and the Bourne again shell (bash). The paper is missing any discussion of prior art. In practice, shell implementations either predate the POSIX standard or were built afterwards and include non-standard extensions. o The paper repeats a claim that the shell has been largely ignored by academia and industry. Yet, it does not include any references that support that claim. My own experience and thus opinion is the opposite making the veracity of your claim questionable. As a reader, such unsubstantiated claims make me treat the entire content as suspect. o The paper applies universal complaints such as "unmaintainable" to the shell; it doesn't call out any shell-specific problems. It doesn't explain whether these complaints are against the scripts, the implementation, or both. One of the reasons for the longevity of the sh/bash shells is that experienced practicioners have been able to write easily maintainable code. Scripts written in the 1980s are still around and working fine. o The paper seems to complain that the fact that the shell is documented is a problem. This is an astonishing statement. In my decades as an acting professional, teacher, and author, proper documentation is a key component of being a professional. o The paper is full of non-sequiturs such as discussions about Docker and systemd that have nothing to to with the shell. o The paper has many "nop" statements such as "arguably improved" that don't actually say anything. o Examples, such as the one on page 105 don't work. o Proofreading should have caught things like "improve performance performance" on page 107 among others. o The references contain many more items than the paper actually references. Did you plagerize the bibliography and forget to edit it? o The single result in Figure 1 is insufficient evidence that the approach works on a wide variety of problems. o The paper makes it appear that the authors don't actually understand the semantics of the original Bourne shell. Not just my opinion; I received an email from Steve Bourne after he read your paper, and I consider him to be a subject matter expert. The paper is lacking the generally accepted form of: o What problem are you trying to solve? o What have others done? o What's our approach? o How does it do? Filtering out all of the jargon added for buzzword compliance, I think that the paper is really trying to say: o Programmable command interpreters such as those found in Unix-based systems have been around for a long time. For this paper, we're focusing on the GNU bash implementation of the POSIX P1003.2 shell. Other command interpreters predate Unix. o This implementation is used more often than many other scripting languages because it is available and often installed as the default command interpreter on most modern systems (Unix-based or otherwise). In particular, it is often the default for Linux systems. o The shell as defined above is being used in ways that are far more complex than originally contemplated when Bourne created the original syntax and semantics, much less the new features added by the POSIX standards committee. The combination of both the POSIX and bash extensions to the Bourne shell exposes a new set of limitations and issues such as performance. o While much work has been done by the bash implementors, it's primarily been in the area of expanding the functionality, usually in a backward-compatible manner. Other shells such as the original ksh and later ash and zsh were implemented with an eye towards the performance of the internals and user perspectives. o Performance optimization using modern techniques such as JIT have been applied to other languages but not to POSIX shell implementations. This paper looks at doing that. It is unsurprising that techniques that have worked elsewhere work here too. o It's hard to imagine that the application of this technique is all that's required for a 50-year life extension. The title of this paper implies that it's going to be comprehensive rather than just being a shameless plus for an author's project. Of course, this doesn't make much of a paper. Guessing that that's why it was so "bulked up" with irrelevancies. It appears that all of you are in academia. I can't imagine that a paper like this would pass muster in front of any thesis committee, much less get that far. Not only for content, but for lack of proofreading and editing. The fact that the ACM would publish such a paper eliminates any regret that I may have had in dropping my ACM membership. [View Less]

3 years, 8 months

The Unix shell: a 50-year view -- second pass feedback wanted

by Jon Steinhart

Thanks to everyone who provided me feedback on the first pass, especially those who suggested "shopt -u flame-off". Here's the second version. Once again, would appreciate feedback. Thanks, Jon I read your "Unix Shell Programming: The Next 50 Years" expecting some well thought out wisdom. I was sorely disappointed. The paper is lacking the generally accepted form of: o What problem are you trying to solve? o What have others done? o What's our approach? o How does it do? Some … [View More]particulars: o The paper never defines what is meant by the term "Unix shell." I think that you're using it to mean a command interpreter as described in the POSIX 1003.2 documents. o There is no 50 year old Unix shell. I started using Unix in the early 1970s, and the command interpreter at the time (Ken Thompson's shell) was nothing like later shells such as the Bourne shell (sh since research V7 Unix), Korn shell (ksh), C shell (csh), and the Bourne again shell (bash). Unix mainstreamed the notion of a command interpreter that was not baked into the system. The paper lacks any discussion of prior art. In practice, shell implementations either predate the POSIX standard or were built afterwards and include non-standard extensions. o The paper repeats a claim that the shell has been largely ignored by academia and industry. Yet, it does not include any references that support that claim. In fact, the large body of published work on shells and ongoing work on shells such as zsh shows that claim to be incorrect. o The paper applies universal complaints such as "unmaintainable" to the shell; it doesn't call out any shell-specific problems. It doesn't explain whether these complaints are against the scripts, the implementation, or both. One of the reasons for the longevity of the family of shells descended from Bourne's sh is that experienced practicioners have been able to write easily maintainable code. Scripts written in the 1980s are still around and working fine. o The paper seems to complain that the fact that the shell is documented is a problem. This is astonishing. Proper documentation has always been a key component of being a professional in my decades of experience. As a matter of fact, my boss telling me that "nobody will give a crap about your work unless you write a good paper" when I was a teenager at Bell Labs is what led me to UNIX and nroff. o The paper includes non-sequiturs such as discussions about Docker and systemd that have nothing to to with the shell. o The paper has many "nop" statements such as "arguably improved" that don't actually say anything. o Examples, such as the one on page 105 don't work as there is no input to "cut". o The single result in Figure 1 is insufficient evidence that the approach works on a wide variety of problems. o The paper gives the appearance that the authors don't actually understand the semantics of the original Bourne shell. Not just my opinion; I received an email from Steve Bourne after he read your paper, and I consider him to be a subject matter expert. o Proofreading should have caught things like "improve performance performance" on page 107 among others. I think that the paper is really trying to say: o Programmable command interpreters such as those found in Unix-based systems have been around for a long time. For this paper, we're focusing on the GNU bash implementation of the POSIX P1003.2 shell. Other command interpreters predate Unix. o This implementation is used more often than many other scripting languages because it is available and often installed as the default command interpreter on most modern systems (Unix-based or otherwise). In particular, it is often the default for Linux systems. o The shell as defined above is being used in ways that are far more complex than originally contemplated when Bourne created the original syntax and semantics, much less the new features from kash adopted by the POSIX standards committee. The combination of both the POSIX and bash extensions to the Bourne shell exposes a new set of limitations and issues such as performance. o While much work has been done by the bash implementors, it's primarily been in the area of expanding the functionality, usually in a backward-compatible manner. Other shells such as the original ksh and later ash and zsh were implemented with an eye towards the performance of the internals and user perspectives. o Performance optimization using modern techniques such as JIT compilation have been applied to other languages but not to POSIX shell implementations. This paper looks at doing that. It is unsurprising that techniques that have worked elsewhere work here too. It's hard to imagine that the application of this technique is all that's required for a 50-year life extension. The title of this paper implies that it's going to be comprehensive but instead concentrates on a couple of projects. It ignores other active work on shells such as "fish". While the issues with the paper remain, they would not have been quite so glaring had it had a more modest title such as "Applying JIT Compilation to the POSIX Shell". [View Less]

3 years, 8 months

Good News:

by Caipenghui

UNIX history memoir has been published in China (publish by posts and Telecommunications Press in China) and translated into Chinese. It is also called name "UNIX legend" in China. I'm going to buy now. If you're in the computer industry, it's exciting just to understand how these buzzwords came into being. Even if you don't have a deep technical background, You can also benefit a lot from these ides that shine with genius. I have been looking forward to a Chinese book about the history of … [View More]

3 years, 9 months

Re: [TUHS] Binary log files

by norman＠oclsc.org

Some of us have, literally for decades, been dealing with wtmp by rolling it weekly or monthly or quarterly or whatever, letting cron run something like cd /usr/adm # that's how long I've been doing this! umask 022 >wtmp.new ln wtmp wtmp.prev mv wtmp.new wtmp # also so long ago there was no seq(1) nums=`awk 'BEGIN {for (i = 12; i >= 0; i--) print i; exit}'` for i in $nums; do inext=`expr $i + 1` if [ -f wtmp.$i ]; then mv wtmp.$i wtmp.$inext fi done mv wtmp.prev wtmp.0 … [View More]

3 years, 9 months

Binary log files

by John Cowan

As long ago as the 7th Edition, several binary log files were maintained: the file generated by acct(2) (one record per process) and the utmp and wtmp files (one record per login). Both of these are defined by structs in .h files, so they are definitely not portable (int sizes, endianism, etc.)

3 years, 9 months

[tuhs] Dennis Ritchie's couch

by Nelson H. F. Beebe

The last article of the latest issue of the Communications of the ACM that appeared electronically earlier today is a brief interview with this year's ACM Turing Award winners, Al Aho and Jeff Ullman. The article is Last byte: Shaping the foundations of programming languages https://doi.org/10.1145/3460442 Comm. ACM 64(6), 120, 119, June 2021. and it includes a picture of the two winners sitting on Dennis Ritchie's couch. I liked this snippet from Jeff Ullman, … [View More]

3 years, 9 months

Re: [TUHS] The Unix shell: a 50-year view

by Jon Steinhart

Wow. This is a terrible paper. It's full of of incorrect, unsubstiantiated, and meaningless statements. It's so bad in my opinion that I'm not sorry that I dropped my ACM membership a while ago. These folks really needed an editor. The paper annoys me so much that I've decided to write a lengthy note to the authors which I'll post here once I'm done. Jon

3 years, 9 months

Disassemblers

by Henry Bent

>From what I can gather the only way to reasonably examine the disassembly of a program in the early days of Unix was adb. Is this true? Was there a way to easily produce a full disassembly? I'll confess to being fairly ignorant of adb use since I always had dbx or the equivalent available. The first tool I'm aware of to purposefully/primarily produce a full listing is MIPS dis (ca. 1986?) but there must have been something before that for other systems, no? -Henry

3 years, 9 months

pointer disambiguation (was Re: Disassemers)

by Paul Winalski

On 7/1/21, scj(a)yaccman.com <scj(a)yaccman.com> wrote: > When PCC came along and started running on 32-bit machines, I started > thinking about algorithms for optimization. A problem that I had no > good solution for could be illustrated by a simple piece of code: > > x = *p; > > y = *q; > > q gets changed > > *q = z; > > The question is, do I need to reload x now because q might have been > changed to point … [View More]

3 years, 9 months

Re: [TUHS] Using printf from Assembly Language in V6, and db.

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley <paul(a)rileyriot.com> >> (I wrote a note, BITD, explaining how all this worked; I'll upload it >> to the CHWiki when I get a chance.) Now here: https://gunkies.org/wiki/PDP-11_C_stack_operation along with simple examples of args and auto variables, which are both referenced via the FP. > As a non-C consumer of printf, should I point R5 at some space for a > stack and call printf in the same manner as the C example I cited? … [View More]

3 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS