dingosity

I like the cut of your jib, @fragmede. Though it's probably more like "Move at a moderate speed and break ice." (Which DOES sound like my company's product development process.)

Oh yeah. This was a snarky comment. Serves me right for trying to be clever over a text channel. It is very easy to misinterpret this as a legit comment.

I probably should have led with "I spent 35 years as a software developer and THEN got an MBA." Which is to say... when I make snarky comments, they're firmly grounded on basic comp sci and extensive software dev experience. However, When I show the kids at work how to use old-school command line tools like awk, sed, cut, grep and find, I leave off the bit that they've been educated by an MBA.

Nope. And I really don't need another lo-rez TV.

Just a reminder... this is from comp.lang.python. It's not unbiased.

Oh man. I have SUCH good memories of my school's SP9000. It was the first machine I really got to use APL with. Thx for digging this up. Also... there were APL compilers back in the day. It wasn't exclusively interpreted.

Meh. I make free stuff and I'm completely okay with people asking for more free stuff. I might be thinking of adding something you say you need, so it's cool to know what other people's requirements are. If they're simple to implement, and other people submit a test case for it, I'm fine with enhancement requests.

HOWEVER...

I've had a few people who say things like "OMG. YOU MUST DO IT THE WAY I THINK YOU SHOULD DO IT" or "ADD THIS FEATURE OR YOUR NOT A REAL OPEN SOURCE CONTRIBUTOR." And that is definitely annoying. I have a thick hide and don't mind just ignoring those people, but that shouldn't be the default assumption. The people who work on open source projects are people, so don't be a pushy jerk when you're requesting features from FLOSS projects.

ALSO...

Let people revel in the approval of their peers before pointing out things you would have done differently. This is a cool bit of kit.

This is fine and all, but in the old days we used to have a "simple" editor bound to $EDITOR and a more advanced editor bound to $VISUAL. But hey, it's YOUR system, so who am I to tell you what to do. Just a reminder that you might find people using $VISUAL instead of $EDITOR. I think common practice for a bazillion years has been setting BOTH $VISUAL and $EDITOR to the full path of your favorite screen editor since hardly anyone needs to worry about editing something on a feature-poor terminal.

And since we're all talking about our favorite uses of $VISUAL and/or $EDITOR, this is mine:

    tcv() {
      if [ "$#" -ge 1 ]; then
        touch $@
        chmod 755 $@
        ${VISUAL:-`which emacs` --color=never} $@
      fi
    }

I use this when I want to write a shell script that's instantaneously executable. I'm much too busy to issue the chmod command after editing the file for the first time.

I think it's used so you can easily run a command using the same environment other npm commands run under.

https://docs.npmjs.com/cli/v10/commands/npm-run-script

Which is to say... I think you can do everything the `npm run <foo>` command does from the command line, but it would require typing a lot more characters. You would have to do something like this to get what running `npm run` does automagically:

    NODE_PATH=./node_modules/.bin node -r ./node_modules/env foo.js

which is more characters to type than

    npm foo

So I guess I can take it out of my closet where it's been sitting, unused, for the last 3 years and finally drag it to eWaste facility.

Google: We EoL more products before breakfast than other companies EoL the whole day.

thx. I searched for it in the github interface and didn't get a hit. funky.

I joke about Gnu Hurd, but it would be great to get actual numbers. Ubuntu used to do this thing where you could put a virtual pin in a virtual map when you installed it to build a heatmap of where users were. It was completely optional at the time (hopefully it still is?) But I think it was enough for Canonical to get a order of magnitude estimate for how many Ubuntu systems were out there.

Gnu Hurd fails the "used by many" clause.

Only if the other planet's orbits take them near enough to the black hole to get sucked in. The main difference between a primordial black hole at about the Earth's mass and a planet at about the Earth's mass is the presumed density of dark matter around it. And I'm guessing there's more hawking radiation coming from the black hole than the planet.

But small black holes with the same mass as the Earth have the same sucking power as the Earth since it's the mass that does the sucking.

I love that there's an ad for Castle Wolfenstein in the middle of Crawford's "The Future of Computer Wargaming" article. If only any of us knew what was coming in a decade w/ Wolfenstein 3D and beyond.

GPLv3 and librepcb-cli source isn't published. what?

Sure. But the benefit of open source is you can do whatever the eff you want. I just don't like being told "I have a use case that dictates your behaviour. You need to follow that use case, even though it's not your use case and contravenes an existing convention."

This is sort of my hot button issue. After years of working on BSAFE, OpenSSL, firefox and libnss, I hate that people say "Hey. Great software. Here's a list of things you must add to it. Of course I'm not going to pay you."

Why should I change my code to adhere to someone else's conventions when they're in opposition to existing conventions?

I think this might be the crux of my discomfort with the OP's exhortation we should all adhere to his preferences. Unix and it's derivatives are great because there's a long history of people trying to do things, finding it hard and then slathering on a layer of functionality which is invoked through abstractions that are novel and probably inconsistent with those abstractions that came before. You don't need to ask anyone's permission and you won't find people saying "meh. you shouldn't do it that way." (okay. maybe a few, but you can ignore them. The Unix(tm) police won't show up to cart you away like what happens with VMS.)

But the flip side of this is, yes, cruft.

Sure. But the comment wasn't "You probably shouldn't be touching the shell if you haven't shipped industry-leading products" it was "You probably shouldn't be touching the shell if you don't know what that does."

Also, if you needed to use it every day, I suspect it would be more familiar than a vague memory.

I can see how that's a reasonable preference. Though I fall in @OjFord's camp. I have a mouse scroll wheel and I'm not afraid to use it. But... I have to remember to hit return a few times beforehand because it's sometimes hard to find the top of help when you're scrolling up in the terminal.

And if your brain is wired for vi, then that makes complete sense.

But... the cool thing about using the scrollwheel to scroll up to see the --help output is it's always there. If you pipe it into less, it disappears as soon as you exit less. So if you're writing a big, beefy command with lots of unfamiliar options, you can start typing down at the prompt and then scroll up to read the help output. It's annoying when you type that you immediately scroll back down to the bottom of the terminal buffer, and I think all terminal emulators default to doing this, but maybe it's a configurable behaviour.

This also works with `man <command> | cat`.

Also... how many times have I had to type out `git branch -a | cat` and tried to remember to put the `| cat` in it. I HATE that the stock git cli automagically pipes to /usr/bin/pager. If I wanted to pipe the output to /usr/bin/pager, I would type `command | /usr/bin/pager`. But now I'm just kvetching.

Sure. I don't need to be a grumpy elitist.

The problem isn't that you get a usage message when you ask for it. It's that you get a usage message (written to STDOUT) when you don't. Many commands will print out the usage message when command line options specify a condition that can't be met. I find this frequently when ssh'ing into busybox based systems. Busybox's find command is much less "refined" than comparable desktop OS finds (BSD & GNU/Linux).

So if I do something like:

  ssh me@foo.example.com "find . -type f | while read line; do sha256sum \$line; done" | tr -s ' ' | cut -f 2,1 -d ' ' | sort | uniq -c

And expect output that looks something like a sorted line of hashes, I will be sorely disappointed.

I believe you have completely misunderstood my "argument".

If the next command in the pipe wants to do something with non-normal output of a command, then yes, it should do something with that. And the command can redirect stderr to stdout with the use of `2>&1`.

Yes. You're unlikely to like my software. I don't recommend you use it.

Let's take the cut command for instance. If you read the man page you discover it's job is to parse fields out of each line of input. Printing a usage message into STDOUT is not part of its documented behaviour. It is therefore an exceptional event.

Just tell people to turn their air conditioning units off for the thirty minutes before and after the eclipse.

Yup. Chuck Peddle (one of the guys largely responsible for the design of the 6502) did an oral history interview with the CHM (Computer History Museum in Mountain View, CA.) In it he discussed their design process. They thought the market for the 6502 was as a controller (cars, HVAC, instrumentation, etc.), not the CPU of a microcomputer. But then Tiny BASIC came along at exactly the right time and hid the messier 6502 design decisions (zero page, weird addressing modes, 256 byte stack, etc.) from a whole bunch of users.

So yes... BASIC is absolutely a contender for small systems. But so are MicroLisp and FORTH. Personally, I prefer Lisp, but completely agree Lisp's learning curve is waaay steeper than BASIC's. Same for FORTH.

Here's the video, btw: https://youtu.be/enHF9lMseP8?si=atmDesKCxN9eH_6R

Just sort of realized I know a guy in San Francisco who owns an Icebreaker. So... I guess the answer is... yes, SOMEONE needs to own an Icebreaker.

This is going to sound snotty, and I'm not really trying to be, but... Unix and its derivatives were made for people who sort of knew what they were doing. The reason you pipe exceptional events to STDERR is so the STDOUT output, if it exists, can flow into the next command in the pipe. Asking for help is an exceptional event. If you want the error output of a Unixish (linux, macos, solaris, etc.) machine running bash to be lessable, re-direct it to STDOUT with `2>&1`. You probably shouldn't be touching the shell if you don't know what that does. These tools were developed assuming the users would have a basic understanding of the system they were running on.

The GNU Project has published tools of varying quality, based on who was around to write the tool, debug it, give feedback, etc. It is not the exemplar of high quality software. (But it's far from crap.) The important bit about GNU (and any other software) is that it was written to adhere to their uses. Other people have different requirements. Telling people to "write your software like GNU writes their software" is to misunderstand personal agency and one of the major points of open source software.

Your comments sound like you're saying "Software freedom means you're free to write software the way I want you to write software."

No thank you.

Still. It's fun when the kids discover hypertext wasn't invented in the 90s.