Problems With UNIX Standards

[SoulofDeity]

So. I was wanting to make my own UNIX system for a hobby project. I see everywhere that the standards are open. POSIX redirects to the SUS (I'm presuming they're now one in the same). I signed up for The Open Group, giving them all my personal information. Can't log in. I go back to the POSIX site and it says that only businesses and corporations can sign up for The Open Group. They then mentioned that the only way for individuals to join the site was to become a member of The Austin Group. This requires you to personally contact some guy named Andrew for permission. If this is the only way for individuals to get their hands on the standards, then I feel sorry for this Andrew guy because his inbox is probably overflowing all the time.

Conclusion
The UNIX specification is not open and the name "The Open Group" is clearly misleading. Rather than just imitating it as closely as possible, I think I'd rather step back and look at what works and what doesn't. I love UNIX systems, but they're not perfect. For example:

• The structure of the filing system is a bit confusing and error prone. eg. The use of '/' as the root directory. Accessing the root directory should be more explicit.
• The use of "-" or "--" for command line options should be replaced with a character that's reserved in filenames.
• There needs to be cleaner audio interface. Perhaps something that works similar to the X Window System.
• There's some obsolete cruftware like SCCS and telnet that can be removed.

Note that I'm not looking to create a new standard. I'm working on a UNIX-inspired hobby OS and am curious about the opinions of other people who have more experience. If you could change anything about the UNIX system (without worrying about compatibility or compliance), what would it be?

[Techel]

Yes, the '/' as the root directory could be a bit confusing. But the other points... You are developing your own OS, so it's up to you

[sortie]

You can find POSIX online at http://pubs.opengroup.org/onlinepubs/9699919799/ legally and freely. The trouble you are seeing are with standards organizations and other silliness. The POSIX standards dating way back are available in this form. Of course, there's advantages to buying a PDF, but I got one free through my university. It's the same text, though.

The structure of the filing system is a bit confusing and error prone. eg. The use of '/' as the root directory. Accessing the root directory should be more explicit.

It makes a bit of sense inductively, but come on. It's reasonable enough, anything else is probably uglier, and it's very compatible. It's not really that confusing.

The use of "-" or "--" for command line options should be replaced with a character that's reserved in filenames.

That's not going to happen. Just don't have leading dashes in your filenames.

There needs to be cleaner audio interface. Perhaps something that works similar to the X Window System.

That's way outside the scope of POSIX. I think there's a bunch of competing things for Linux, but I never looked into it.

There's some obsolete cruftware like SCCS and telnet that can be removed.

Nobody cares about SCCS. It's in POSIX as a XSI option for some weird reason. It's basically optional and not part of the core standard. Telnet is its own thing, it has a protocol, it's up to the users. I don't think it's in POSIX. nc(1) is a better replacement for telnet if you want a raw tcp stream.

You are willing to leave compatibility behind, and I do commend that. But really, I think there's a lot of value in almost compatible improvements. For instance, there's a bunch of cruft in POSIX and existing systems that should be removed. For instance, I am removing mktemp(3) from my OS these days. I got a list of obsolete stuff that I either refuse to implement in my OS or that I am phasing out. Incompatibility has a price, always, so pick your battles. If you entirely drop compatibility, you got to write all the software yourself. I instead embrace that which is good enough, remove the cruft, make it better, and drag up existing software.

So I'm not really having changes to Unix, I'm making it work.

[SoulofDeity]

Thanks for the link

What I was trying to access on the open group site was just the HTML files. They were labelled "FREE", but you had to register on the site to get them (which of course, they don't let you do that easily as I found out).

Aside from confusion, one reason that I brought up the '/' root path was security. None of the UNIX tools question the actions of the root user, and when you don't make absolute paths explicit, you make it extremely easy to accidently destroy your filesystem by forgetting a single character.

If you did stop treating '/' as root, then it could be used for command line switches like in Windows and you don't have to trust people not to add leading dashes to filenames.


I'm not 100% sure if SCCS or telnet are part of the standard. I assumed so as most systems I've used have had them. The reason I mentioned them in particular are that rcs and nc supersede them. But anyhow, I'm pretty much wanting to do what you said you were doing. Removing the cruft and keeping what's good about it. That list will be very useful.

[Brynet-Inc]

It really isn't difficult joining the Austin Group to get the PDF, he replies pretty quickly and you are under no obligations to participate. I know at least two other people here that signed up successfully.

If the online reference that sortie linked is inconvenient for you, they do provide downloads for them as well.. HTML of course.

http://pubs.opengroup.org/onlinepubs/96 ... index.html

The PDF is useful if you ever plan on participating though, see here.

[sortie]

Aside from confusion, one reason that I brought up the '/' root path was security. None of the UNIX tools question the actions of the root user, and when you don't make absolute paths explicit, you make it extremely easy to accidently destroy your filesystem by forgetting a single character.

Actually, this solves nothing and potentially could cause new kinds of trouble. Imagine if the root directory must be explicitly specified as ROOT@ and a traditional path like /home/sortie/foo would then be ROOT@home/sortie/foo. Imagine the command that deletes a directory would then be: rm -r ROOT@home/sortie/foo. Okay, so good. But like /, ROOT@ is just a magical prefix. Imagine a script that tries to delete a directory, but the variable was unset. It could then easily end up running rm -r ROOT@ by accident and deleting it all. Or imaging downloading a script, and it got truncated at the wrong location, just after the @ character. Or imaging an administrator that wants to remove ROOT@var/logs/sillyprogram/ but ends up pressing enter prematurely after entering the @. The new magical prefix doesn't solve these issues. It just changes the stuff that must be typed, but there's still a lot of unsolved dangerous cases.

[SoulofDeity]

@sortie True, but if you screw up there then what goes wrong will be far less severe. It'd be highly unlikely that another variable would get confused with ROOT by mistake, unless some program decided to make an environment variable called ROO, ROT, or OOT which is clearly a deliberate attempt at taking advantage of human error no matter how you look at it. Worst case scenario, you'll destroy the local directory. I'd prefer that any day.

Best case (and most likely case) scenario, ROOTsomedirectory does not exist so you just get shown an error message.

[sortie]

Except that because of the new, longer prefix, ROOT@ will be hard-coded everywhere, and it's likely it appears in a variable by mistake.

Curiously, this design also invalidates the Unix concept of prefixes, where DESTDIR during installation serves as another prefix.

[SoulofDeity]

Except that because of the new, longer prefix, ROOT@ will be hard-coded everywhere, and it's likely it appears in a variable by mistake.

It's no different than typing "~/" to get to the home directory. I was just going along with your example, but my original idea was something like "!/" being used for the root directory. This would make it so that shebangs in scripts don't have to be changed.

[sortie]

I was just going along with your example, but my original idea was something like "!/" being used for the root directory. This would make it so that shebangs in scripts don't have to be changed.

LOL

Everything but shebang scripts would have to change. lol.


(It's actually pretty funny - not trying to be an @$$)

[SoulofDeity]

LOL

Everything but shebang scripts would have to change. lol.


(It's actually pretty funny - not trying to be an @$$)

I seriously completely forgot about that when posted that reply, lol. Well, anyhow, it would fix a lot of problems. If you wanted to go the windows route and use an environment variable (%SystemDrive% -> $ROOT) then there would be no need for a dedicated chroot command. Plus there's already a $HOME variable, so it's no biggie.

I'm not worried about breaking compatibility. Unix systems have sort of just become giant balls of cruft. Some things in them are really big or not truly teletype compatible. I believe this breaks away from the original goals which were portability, KISS, and "do one thing, and do it well"

[iansjack]

Windows needs an environment variable to specify the root because each disk has its own root and there's no easy way to tell which is the System Drive. It's not necessarily "C:/". Unix doesn't need that; it has one unique root. Omitting the leading character is likely to be a non-destructive error as any command then applies to a more restrictive set of files (in general). "rm -rf usr" is far less dangerous than "rm -rf /usr".

You have to remember that Unix was designed to be used by people who knew what they were doing and wanted to do it without unnecessary typing - thus "ls" rather than "dir", etc. And it's much easier to type "/usr" than "$SystemRoot/usr" or even the abomination that you suggest "!/usr". And let's not forget that "!" is a valid Unix filename, so how is "!/usr" to be interpreted?

[SoulofDeity]

were doing and wanted to do it without unnecessary typing - thus "ls" rather than "dir", etc. And it's much easier to type "/usr" than "$SystemRoot/usr" or even the abomination that you suggest "!/usr". And let's not forget that "!" is a valid Unix filename, so how is "!/usr" to be interpreted?

"~" is also a valid Unix file name, as is "-", "--", and (if you really want to piss off someone who's a newbie to Unix systems) "-rf". Windows has even worse reserved names like COM, NUL, and PRN. Personally, if someone were to send me a complaint about not being able to name a open a file they called "!", I would first point and laugh at them, then I'd say, "use './!'". This is one of the reasons simply omitting the leading '/' isn't a solution.

[Brendan]

Hi,

were doing and wanted to do it without unnecessary typing - thus "ls" rather than "dir", etc. And it's much easier to type "/usr" than "$SystemRoot/usr" or even the abomination that you suggest "!/usr". And let's not forget that "!" is a valid Unix filename, so how is "!/usr" to be interpreted?

"~" is also a valid Unix file name, as is "-", "--", and (if you really want to piss off someone who's a newbie to Unix systems) "-rf". Windows has even worse reserved names like COM, NUL, and PRN. Personally, if someone were to send me a complaint about not being able to name a open a file they called "!", I would first point and laugh at them, then I'd say, "use './!'". This is one of the reasons simply omitting the leading '/' isn't a solution.

For POSIX filenames, the only characters that are reserved are '/' and zero.

This means you can have all the whitespace characters (including zero-width spaces and non-breaking space and "vertical tab"); and file names with the bell character.

You could probably have a directory full of files that have "whitespace and bells only" file names, so that if someone does "ls" on a terminal connected via. slow serial it plays a tune while clearing the screen.


Cheers,

Brendan

[gerryg400]

Aside from confusion, one reason that I brought up the '/' root path was security. None of the UNIX tools question the actions of the root user, and when you don't make absolute paths explicit, you make it extremely easy to accidently destroy your filesystem by forgetting a single character.

The unix tools WILL question the user if the user wants them to. Just type "rm -i" if you feel you need to be queried. Additionally the root directory usually has its permissions set such that you cannot delete items from it. I really think you are imagining a problem where there actually isn't one.