181–190 of 222 posts
Earlier quoted context omitted.
The syntax is common to most JCL ("job control language") commands. I'd say "all", though there are probably exceptions. For some reason, this seems to be vanishingly scarce knowledge in Linux / Unix circles. There was a time in my life I knew how to spell JCL....
More in this area: http://www.catb.org/esr/faqs/things-every-hacker-once-knew/
If Apple made the transition to OS X in a position of strength, like the one it enjoys today, I think it may had imposed a pattern and rewritten tar, ps, dd, etc. However, the way history has unfolded, I think we’re stuck with this mess for good.
I mean, you really think its "position of strength" didn't come from it embracing Unix compatibility (which let it welcome the flood of web developers)?
If Apple made the transition to OS X in a position of strength, like the one it enjoys today, I think it may had imposed a pattern and rewritten tar, ps, dd, etc. However, the way history has unfolded, I think we’re stuck with this mess for good.
In that case, there wouldn't be any desktop UNIX from Apple, and Copland would have managed to eventually make it.
Being huge and powerful is no guarantee of success when it comes to shipping software. Size can often be a hinderance.
If Apple made the transition to OS X in a position of strength, like the one it enjoys today, I think it may had imposed a pattern and rewritten tar, ps, dd, etc. However, the way history has unfolded, I think we’re stuck with this mess for good.
Perhaps Apple's biggest contribution to the Unix/Linux landscape was launchd, which inspired systemd. I don't know if we would've endeavored in rewriting essential and mostly working decades-old parts if there wasn't a proven path already laid out.
Maybe LLVM as well, a modular compiler toolchain, but that's a strech.
I was at Bell during the options “debate.” I think something that this otherwise wonderful article misses is that some believed that commands were never intended to be the only way to use the system as the shell was intended to be just one of the many user interfaces that Research Unix would provide. From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options t…
Earlier quoted context omitted.
> six lines of McIlroy’s shell pipeline accomplished the same thing as Common misconception. See https://buttondown.email/hillelwayne/archive/donald-knuth-wa... ("Donald Knuth Was Framed") and discussion at https://news.ycombinator.com/item?id=22406070 (etc).
How is it a misconception? My overall point was that shell oneliners are often much faster to quickly bang out for a one-off use case than writing a full program from the ground up to accomplish the same thing. This is demonstrated to a very exaggerated degree in the Knuth vs. McIlroy example, but it also holds true for non-exaggerated real-world use cases. (I had a coworker who was totally shell illiterate and would…
Taking 10x longer doesn't seem like a language problem. If you don't know bash well you're going to take even longer to do it in bash than in python.
In any case the task you described is pretty much the same in python as in bash. At worst the python is going to be more more verbose.
python -c "print(len(set(w for l in list(open('test.txt')) for w in l.split())))"
tr ' ' '\n' Earlier quoted context omitted.
A shell is just how you interact with the underlying system. The gui is also a shell. Confusing I know!
I like to see it this way: A shell /wraps/ the kernel. You cannot issue system calls directly, but a program that handles user input generically (and ideally dynamically), can do this for you. A desktop environment, Emacs, and to an increasing degree web browsers are all different "shells".
Any user-space executable can issue system calls, the shell isn't special there.
Earlier quoted context omitted.
The `-z` on extract is not needed on basically most modern tar implementations (OpenBSD's is I believe the one outlier). tar -xf foo.tar.gz (or .xz, .bz2, .zst, etc.) will work, auto detect the archive type and extract.
OpenBSD, which is a fork of NetBSD, is not the only "outlier".^1 For many years, NetBSD tar has autodetected bzip2 compression. tar xzf 1.tar.bz2 will work on gzip as well as bzip2. Whereas GNU tar still requires "j" instead^2 tar xjf 1.tar.bz2 1. For example, FreeBSD or MacOS tar is BSD tar. It will autodetect bzip2 compression. 2. The GNU tar included with VoidLinux still requires z or j. The pax(1) utility is the…
The following should work, it worked on my Arch Linux install (but note that auto detection is not a "new" feature to GNU tar, I've been using it for at least 5 years)
echo "Hello" > foo.txt
tar cjf foo.tar.bz2 foo.txt
rm foo.txt
tar xf foo.tar.bz2
cat foo.txt
To be clear, I'm not saying the following should work
tar xzf foo.tar.bz2
tar xf foo.tar.bz2
$ tar --version
tar (GNU tar) 1.34
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by John Gilmore and Jay Fenlason.Earlier quoted context omitted.
I am annoyed go's flags package did not respect the GNU convention for options, which I agree is the best.
I am not too surprised that the confluence point between Plan 9 and Google have little interest in following the GNU way.