cmdmp3 VS coreutils

Some things I built on the side, outside of my day job:

In the late 90's, I sold a command-line SMTP e-mailer for Windows. It was easy enough for folks to integrate e-mail transmission into their systems ... even 16-bit systems since spawning a copy of the shell would allow 16-bit systems to invoke my 32-bit mailer. Lots of folks had used these tools for all sorts of things. I got registration checks and cash from around the world before I started taking credit card payments.

I have an open source command-line MP3 player for Windows that folks still use and incorporate into their systems, JS libraries for node.js, ...etc.

https://github.com/jimlawless/cmdmp3

I wrote a command-line MP3 player in C for Windows. I just wanted to play with the media manger API's, but I've ended up using this to play MP3's in succession via a script.

https://github.com/jimlawless/cmdmp3

It doesn't work on all versions of Windows ... it depends on some configuration elements. This has been used in another developer's video game and I believe it's installed with an MP3 player library in node.js ( if you're running node.js under Windows. ) It also plays WAV files on Windows 10 (possibly 11) if you pass the name of a WAV file into the command-line.

I needed a command-line emailer that would send an email with a very simple one-line body for my Mac. I also wanted to exercise Go's SMTP libraries while experimenting with trying to build a minimal emailer application.

https://github.com/jimlawless/gsend

I use this regularly. I used to use it on MacOS, but I use it more frequently on Windows.

https://github.com/coreutils/coreutils/commit/fcfba90d0d27a1...

A summary of other changes just released in GNU coreutils 9.5 are:

* mv accepts --exchange to swap files

> some are simple like yes(1)

Not that simple: https://github.com/coreutils/coreutils/blob/master/src/yes.c

The -S / --split-string option[1] of /usr/bin/env is a relatively recent addition to GNU Coreutils. It's available starting from GNU Coreutils 8.30[2], released on 2018-07-01.

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works for OS's that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

Fortunately this non-standard behavior is more the norm than the exception: it works at least on modern GNU/Linux, BSDs, and macOS.

[1] https://www.gnu.org/software/coreutils/manual/html_node/env-...

[2] https://github.com/coreutils/coreutils/blob/b09dc6306e7affaf...

> building a cat from scratch

> That would be an interesting project.

Here is the source code of the OpenBSD implementation of cat:

> https://github.com/openbsd/src/blob/master/bin/cat/cat.c

and here of the GNU coreutils implementation:

> https://github.com/coreutils/coreutils/blob/master/src/cat.c

Thus: I don't think building a cat from scratch or creating a tutorial about that topic is particularly hard (even though the HN audience would likely be interested in it). :-)

the yes command, writing to /dev/null, is making IO calls, which interfere with predictable scheduling.

If you look at the source code for yes, https://github.com/coreutils/coreutils/blob/master/src/yes.c

it builds a buffer of output and then writes that in a for loop

  while (full_write (STDOUT_FILENO, buf, bufused) == bufused)

Looking at the source of nohup, if the execvp() of the child happens then it _must_ have already done the signal (SIGHUP, SIG_IGN) so - WTF?

This got me wondering so I went and looked and it seems like lo and behold there was actually a commit to the GNU ls source just 2 weeks ago.

https://github.com/coreutils/coreutils/blob/master/src/ls.c

"maint: prefer char32_t to wchar_t"

even an empty file? Yes. so now it was a file with a copyright disclaimer and nothing else. And the koan-like question comes to mind is "Can you copyright nothing?" well AT&T sure tried.

Then somebody said our programs should be well defined and not depend on a fluke of unix, which at this point was probable a good idea. so it became "exit 0"

Then somebody said we should write our system utilities in C instead of shell so it runs faster. openbsd still has a good example of how this would look.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....

At some point gnu bureaucracy got involved and said all programs must support the '-h' flag. so that got added, then they said all programs must support locale so that got added. now days gnu true is an astonishing 80 lines long.

https://github.com/coreutils/coreutils/blob/master/src/true....

http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html

> Yes, ls is maintained. Although, maintained is a very strong word. It exists.

Why would it be a strong word? Here it is, in src/ls.c: https://github.com/coreutils/coreutils

It is then packaged by tens of operating system distributions, who themselves maintain extra patchsets, some of which are then upstreamed.

It is installed and used on millions (billions?) of devices, for 3 decades.

It's a very reliable and trusty "sharp stick of metal" :)