Posts by geoff61

Ghost in the shell script: Boffins reckon they can catch bugs before programs run

What version of rm accepts a -y option? I've never encountered one.

Re: rm -rfy / useful?

There is one, and only one, valid reason for a shell script to pass '/' (or any other pathname that resolves to the root directory) to rm, and that is to test that it reports an error, as required by POSIX (which says "if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands").

Google admits it deleted some customer data after 'technical issue'

Photos on the timeline?

"creepier still once you realize Google makes it possible for photos to appear on the Timeline too"

Is that still working for anyone since the change to storing timeline data on the phone? I'm not seeing photos in my timeline now.

Re: Google admits it deleted some customer data after 'technical issue'

The data in question, i.e. the Maps timeline, is stored on the phone with an optional backup to the cloud. The deletion must have been caused by a bug in the Maps app.

The people who opted to enable the backup are able to restore the data to their phone. Seems to me that choice is not moronic at all.

Undergrad thought he had mastered Unix in weeks. Then he discovered rm -rf

Re: what does ~* do?

If it's a tcsh quirk, it has been changed since the events recounted here:

$ tcsh -c 'echo ~*'

Unknown user: *.

Photoshop FOSS alternative GNU Image Manipulation Program 3.0 nearly here

Learning GIMP

I learned from the official user manual. Effectively what is now at https://docs.gimp.org/2.10/en/ but the version that was current 23 years ago.

Apple macOS 15 Sequoia is officially UNIX. If anyone cares...

Re: No support for POSIX message queues in macOS

Yes, POSIX calls it "the Message Passing option". It's one of a long list of options whose support can be queried via constants in <unistd.h> and calls to sysconf(). Some of the POSIX options are mandated for UNIX conformance, but Message Passing isn't one of those.

Jason, you're a little out of touch. There *were* three language bindings, but 1003.9 was withdrawn in 2003 according to https://standards.ieee.org/ieee/1003.9/1440/ and although 1003.5 doesn't seem to have been withdrawn, I can't find anything more recent than "Amendment 2", published 31 Dec 1999 (https://ieeexplore.ieee.org/document/815314) and that had Ada bindings to the ancient 1003.1-1996 C interfaces, three major revisions behind the current 1003.1-2024 standard, so it's questionable whether it is relevant any more. Also, although the shell and utilities *were* standardized in 1003.2-1992, 1003.2 was merged into 1003.1 in 2001, as I pointed out in an earlier comment.

(Note that I don't count 1003.1-2017 as a major revision, as it was just 1003.1-2008 with its two technical corrigenda rolled in. The reason it was produced is because IEEE rules require standards to be either revised or withdrawn after 10 years, which means that the IEEE website not showing the 1999 amendment to 1003.5 as withdrawn may be a mistake.)

Geoff Clare

Current Technical Editor of POSIX.1 and The Single UNIX Specification.

Re: Looking in odd places...

The output of "apt-cache show pax" includes: "This is the MirBSD paxtar implementation supporting the formats ar, bcpio, cpio, SVR4 cpio with and without CRC, old tar, and ustar, but not the format known as pax yet."

It likely conforms to POSIX.2-1992 but since it doesn't support the new "pax" format (i.e. "-x pax" in addition to the old "-x ustar" and "-x cpio") it doesn't conform to the later POSIX revisions and wouldn't be sufficient for a UNIX 03 certification.

Re: POSIX.1 vs POSIX.2

POSIX.2 was merged into POSIX.1 in 2001. If you poke around in those links to the 2004, 2017, and 2024 revisions you'll find the shell and utilities stuff is in there.

Re: Am I missing something?

UNIX certifications are for a specific OS on a specific hardware platform. Apple have had separate Intel and ARM certifications for every macOS release since 2020 (Big Sur). Back in the day, Solaris had separate SPARC and Intel certifications.

Sweet 16 and making mistakes: More of the computing industry's biggest fails

Atari UNIX

Followed the link to the atariunix.com site and it brought back some happy memories of having a TT running SVR4 as my personal workstation for 3 years when I worked for UniSoft (who did the SVR4 port) in the 1990's. It had a fabulous 1280x1024 monochrome monitor, whereas the machine I had after that was a Dell PC (also running SVR4) which could only manage 800x600 (but with colour). SVR4 was installed on an 80MB hard drive and used almost all of it. I had a huge (physical size) 100MB external SCSI drive for my files. Part of my job was to run the X/Open XPG3 test suite on it (an ancient ancestor of The Open Group UNIX test suite that is used today to certify AIX, macOS, etc.).

How to maintain code for a century: Just add Rust

chmod without octal

"Ever used octal? You will with chmod."

I am a frequent user of chmod and I can't remember the last time I used it with octal. It's almost always quicker and/or easier to use its symbolic capabilities. For example, a command I use a lot is "chmod a-w file" to make a file read-only. To do the same using octal would mean performing these steps:

1. Use "ls -l file" to see the current permissions

2. Mentally work out what the new permissions will be without any w's

3. Mentally convert the new permissions to octal

4. Use "chmod octal file" to set the permissions

5. (optional, but a good idea) Use "ls -l file" to check the permissions came out right

Even if you want to set the permissions to something fixed, there's no need to use octal. Want read+write for the owner and just read for group and other? You can use "chmod u=rw,go=r file" - slightly more typing than "chmod 644 file" but no mental gymnasitcs needed.

SUSE Linux Enterprise 15 to receive support right up to end of Unix epoch

Unix epoch

There are two problems with the use of the phrase "end of Unix epoch" here.

1. Although in general use, "epoch" can mean a period of time, in computing it is an instant in time. As per Wikipedia's entry for Epoch (computing): "In computing, an epoch is a fixed date and time used as a reference from which a computer measures system time. [...] Unix and POSIX measure time as the number of seconds that have passed since Thursday 1 January 1970 00:00:00 UT, a point in time known as the Unix epoch."

2. The end point for representable time_t values on Unix and POSIX systems varies according to how time_t is defined. It is in 2038 for 32-bit signed time_t, but much later for 32-bit unsigned time_t or for time_t with more than 32 bits. In fact, the latest revision of the base volumes of The Single UNIX Specification (aka POSIX.1-2024, published earlier this month) requires implementations to have a time_t of at least 64-bits. This makes the limit on representable times not time_t, but the tm_year member of struct tm, which (with 32-bit int) can only represent times to a little over 2 billion years from now.

Forgetting the history of Unix is coding us into a corner

Linux certified as UNIX

> in the Open Group register of UNIX® certified products, there used to be two different Linux distros, Huawei EulerOS and Inspur K/UX, both Chinese CentOS Linux derivatives. Like it or not, this means that Linux isn't "a Unix-like OS" any more. It is a Unix.

No, it means that those two specific Linux distros are (or were) UNIX. Huawei and Inspur would have had to make a huge amount of changes to their systems in order to pass the certification tests, similar to what was done by Apple to OS X (as described by Terry Lambert in a post to Quora). In fact, it could be argued that those changes mean EulerOS and K/UX are no longer Linux, since Linus Torvalds famously refused to make at least one of the changes that would be needed to make the kernel conform to POSIX. (The one I'm sure of is that POSIX requires kill(-1, sig) to include the calling process in the set of processes the signal is sent to, but Linux doesn't include it; I vaguely recall there were more such cases.)

Zen Internet warns customers of an impending IP address change

Likewise. (December 2002 to be precise.)

Unix is dead. Long live Unix!

Re: UNIX and POSIX?

They haven't been separately maintained since the late 1990's. After POSIX.1-1996 and The Single UNIX Specification version 2 (SUSv2, 1997) were published, IEEE, The Open Group and ISO got together and formed The Austin Group, a technical working group which created a joint standard that was published as POSIX.1-2001, SUSv3 and ISO 9945-1:2002 (likewise for subsequent revisions). They are three names for one and the same document. (Actually that should be "the base volumes of SUSv3", as SUSv3 also has a separate XCurses volume.)

The distinction between POSIX(TM) and UNIX(R) in the joint standard is that it has a lot of functionality that is optional for POSIX conformance but is mandatory for UNIX conformance (in particular the "XSI option", but other optional things too).

Universal Unix tool AWK gets Unicode support

POSIX conforming awks have supported UTF-8 for almost 30 years

Interesting that the author mentions POSIX systems are required to include awk but doesn't seem to realise that POSIX also effectively requires awk to support UTF-8, and that all of the systems which were updated to conform to POSIX.2-1992 and which added UTF-8 locales in the early to mid 1990's added UTF-8 support to awk (and all the other POSIX text-processing utilities) at that time. I say "effectively" because it's only required on systems that have at least one UTF-8 locale installed, so there's a loophole there; for some systems there may have been a short time where they supported older multi-byte encodings in awk before they added any UTF-8 locales. (UTF-8 was invented by Ken Thompson and Rob Pike right around the same time that POSIX.2-1992 was approved by IEEE).

Init freedom declared as systemd-free Devuan hits stable 1.0.0 status

Happy with systemd? You won't be one day

To those who said they voted no because they haven't had any problems running systemd: more fool you. You almost certainly will have problems one day. Problems happen when you do something that is outside your normal routine. For example...

I have a six-month old Dell XPS 13 that came with Ubuntu pre-installed. I tried out Ubuntu for a few days and all seemed fine, until one day I booted into recovery mode. I was happily typing commands into the recovery mode shell when all of a sudden systemd pipes up that something has timed out and it is going to start an emergency shell. I now have two shells running, both reading from the same terminal. And they are not getting one line of input each or one character, but something in between, which made getting out of the situation an interesting problem-solving exercise. Needless to say the next thing I did was to install a different Linux system with good old sysv init. (Not Devuan as I didn't think it was mature enough at the time, although I may switch to it sometime.)

Shattered Skype slowly staggers to its feet after 15-HOUR outage outrage

Re: Suggestions for alternatives that actually work on Linux please...

Google Hangouts works well on Linux.

Re: Have a backup solution...

The obvious alternative for voice and video is Google's Hangouts. I wouldn't be surprised if many people, on testing it out as a backup for when Skype is down, find that they prefer Hangouts.

OpenStack's success depends on IBM and HP's tech queens

X/Open and Windows NT

Your knowledge of UNIX/POSIX certification history is seriously lacking.

Windows NT was never certified by X/Open. It (or more specifically, its POSIX subsystem) was certified by NIST as conforming to FIPS 151-2, which was basically POSIX.1-1990 with a few optional things mandated, i.e. way less functionality than what X/Open certification would require.

Also, X/Open did not "collapse" - it merged with OSF to form The Open Group, which owns the UNIX® trademark and still certifies UNIX systems. The most recent UNIX certification was OS X Yosemite. See http://www.opengroup.org/openbrand/register/brand3607.htm