Long ago, in Seventh Edition UNIX (a/k/a V7), there was a program called prep. Its primary use was to take files of text, and break them up into one word per line, for further processing by other tools in a pipeline. It could do a little bit of other manipulation too, like telling you the location of each individual word within a file, ignoring specific words in an ignore list, or only paying attention to words specifically mentioned in an include list. It's sort of difficult to explain exactly what it does, but here is a man page from 2.9BSD for it. It had an assortment of interesting uses - for example, building dictionaries, spell-checkers, and the like. This program was rather short lived. It only existed in V7 and a couple of offshoots (and 2.9BSD was basically an offshoot of V7). It didn't previously exist in V6. It was removed from V8. It never even made it into 4.2BSD. It doesn't exist (at least not in this form) in any Linux distribution that I'm aware of, nor in FreeBSD and friends. There was another program that also (as far as I am aware) first appeared on V7, called deroff, that was primarily for a completely different purpose - but it had a "-w" option that told it to do the "split up files into one word per line" thing, similar to prep, but didn't do any of the other functions (like word numbering, include lists, and ignore lists). I assume for purposes like dictionary building, deroff -w subsumed the function of prep. That was comparatively much longer lived - but these days, there doesn't even seem to be a version of deroff packaged for any major Linux distribution, I know it's not in any recent version of RHEL, it's not in Fedora 32, and it's not in Debian 10 (but I'm pretty sure it actually was in Debian until not that long ago). Why did prep go away? Was it really because deroff -w duplicated most of its function? I presume that deroff has disappeared in current Linux distributions because people generally don't deal with [nt]roff-formatted documents anymore, except maybe for man pages. But with both of these tools gone, what can one use to do the "split up a text file into one word per line" function? Is there anything packaged for any modern Linux distro that would perform this function? (If you're going to respond with, "you can probably do this yourself with a simple script", I concede that is probably correct - but that is not the answer I'm looking for right now, I'm looking for a way to do this with some existing tool that already exists in modern Linux distributions...) Ideally, I'd like to find something that implements all the features listed in the man page I linked (plus the "implied" behaviors that aren't explicitly specified in the man page, like not considering punctuation to be part of a word, and how numbers that appear as part of a "word" are handled). :-) Practically, I don't think the include and exclude lists are particularly crucial, and while I'd like to have the word numbering (it can sometimes be handy to know the location of a word in a file), it's not that important. Handling of hyphenated words at the end of a line would be desirable.

How did old Unix systems bill users? I read about some old CS courses where you could waste your budget with infinite loops.

Unix provides standard output and standard error, which can be redirected independently. $ ls /not-exist ls: cannot access '/not-exist': No such file or directory $ ls /not-exist > redirect.out ls: cannot access '/not-exist': No such file or directory $ ls /not-exist 2> redirect.err $ I heard there's a story somewhere on the Web, which gives a fun reason why this separation was implemented. It involves the computerized typesetting that early Unix was used for (and Unix pipelines, I think). I failed to find it right now. Would anyone like to link that story here, to associate it with the relevant tags and make it easier to find?

Preferably USB as it would be easier to carry arround and install on other systems I have never used Unix. My first PC was a windows XP laptop when I was about 8 years old. i have installed Linux, DOS, Windows 95 and a lot of other things. Unfortunately I cannot find any information on flashing Unix to a USB or the order of flashing it to a CD or floppy disk. Is there anyone who knows how one would achieve this? I have a wide range of old hardware that sounds perfect for a Unix cluster of some kind but can't find any info on how to flash Unix to some installation media.

I have installed a VirtualBox VM of UNIX System V Release 4.2 and have discovered just how barren the internet is on documentation of it. Only a few modern commands exist, although obviously because the shell is just sh, not bash, which I'm more used to. I can't get syntax help without man and there doesn't seem to be any help or --help. And I have to use "-linux" (subtract results with term 'linux') in all Google searches to get any semi-useful results. Try as I might, I cannot find anything that has the old commands listed for finding the system's IP address, and nothing useful shows up for finding it directly in VirtualBox's settings. I have the network setup packages which came with the old system so I want to see if it can at least try to see the network, but in order to install them I need the IP. Please help if you have any experience at all.

I have been using Linux & Unix for a long time. The first time I learned Unix is in a computer classroom with many students, where the instructor told us that you can use ssh to log in to remote workstations provided by the university I was studying in. In that context, I immediately know that Unix is a multi-user operating system because there were more students than workstations. (Pigeonhole principle.) Somehow after many years of use, I know basically what the umask (default to 022 for write permission to the user, 002 for write permission to groups of users such as teams) is and that the default permission of a user (and a new user) is 755 for folders, 644 for files. But after thinking a little deeper about it, it seems that the default permission setting is insecure in such a multi-user operating system. Although it makes sharing data easier, I still feel strange when you can easily list & copy other users' files within their home directory. So is why the default umask 002 or 022 in many Unix systems? Is there any historical reason that *traditional* Unix chose this design? (One possible reason I can think of is that, during 1970 ~ 1980 computers are used mostly in scientific research and the computing power is very limited. So when the early version of Unix comes out, they decided that the default permission should be for easy sharing instead of privacy protection.)

I understand the concepts of terminal, console, shell and their differences. I know a shell today is an interpreter that communicates with the OS kernel to perform some actions and does it through terminal applications. But in the old days when computers didn't had GUI, all the interaction a user had with a computer was through the shell? I've read that the Bourne Shell (sh) was introduced in Unix version 7, was that like, you turn on the computer and from the moment you start typing you are communicating with sh? or you had to enter the sh program through a command and then that shell starts? And kind of the same with windows or Mac, is that MS-DOS functionality what we have today in cmd? Thanks in advance and if someone can leave a documentation where this evolution is explained I'll be very grateful.

Is it "user mask" or something? [Wikipedia](https://en.wikipedia.org/wiki/Umask) does not have details, but says the feature has been in Unix since 1978. POSIX just says it is the "file mode creation mask".

stdbool.h is usually defined as: #define false 0 #define true 1 (Sources: OpenBSD , musl , etc.) whereas the unix program false - which just has a unsuccessful status code, is defined as: int main(int argc, char *argv[]) { return (1); } for completeness, the definition of the unix program true is: int main(int argc, char *argv[]) { return (0); } So clearly, it is the complete opposite of the value of false in stdbool.h. I have used the version from OpenBSD as the version from coreutils is more verbose What is the historical reason to make these different?

I recently became curious about history of modern operating systems. Since the best way to learn is to see yourself - I would like to ask: Is there a way to download and install Unix System III on a modern laptop? Preferably without emulator.

I initially thought to post this to StackOverflow because my interest was primarily from a programming focus, but after reading about [the history tag](https://stackoverflow.com/tags/history/info) (and [the question it linked to](https://meta.stackoverflow.com/questions/276366/are-questions-about-programming-history-in-scope-for-stack-overflow)) , I [posted it to softwareengineering.se](https://softwareengineering.stackexchange.com/questions/423020) to get insight on the practical/present-day "software engineering" aspects. The fundamentally historical nature of my question was unavoidable, however, so now it's over here. --- I'm currently getting orientated about how logging works on Linux, and am a tad confused about an implementation detail seemingly not covered by [RFC 5424](https://www.rfc-editor.org/rfc/rfc5424) or [RFC 3164](https://www.rfc-editor.org/rfc/rfc3164) : the format used to write data to /dev/log. ***TL;DR:* I'm trying to identify a) what "the /dev/log format" is called, and b) where its semantics are formally specified. I have been unable to identify any RFC or other citable reference for either - only code implementing specific rules without rhyme or reason.** While I initially became interested in the subject while evaluating the pros and cons of syslog() versus other logging strategies (writing to stdout/stderr and/or files; sending to other types of logging servers; etc), at one point I realized I was completely unable to identify how/where "the /dev/log format" fits into the bigger picture. Every single question out there about syslog formats or protocols discusses the RFCs, and completely ignores what rules govern how data leaves syslog() and makes it to the syslog server in the first place. It's almost like this specific corner of UNIX has disappeared so completely into the woodwork, it's like no longer exists... all while trillions of log messages get written using this "format"(?) every day. So, this question is an attempt to try to disambiguate this particular detail, simply for the sake of doing so, characterize the format, and identify citable references. --- Log lines seem to need to be formatted in a very specific way to be accepted (in my case by systemd-journald - firstly priority/facility information (enclosed in ``), followed by a very specifically-formatted timestamp, what seems to be commonly referred to as a *tag*, and then the message:

# logger -s hi
Mar  5 14:04:11 i336: hi

# journalctl -qn1 -o short-iso-precise
2021-03-05T14:04:11.430504+1100 h0nk i336: hi

# logger -s -t tag hi
Mar  5 14:04:37 tag: hi

# journalctl -qn1 -o short-iso-precise
2021-03-05T14:04:37.050891+1100 h0nk tag: hi

# logger -s -t tag -i hi
Mar  5 14:04:40 tag[3248]: hi

# journalctl -qn1 -o short-iso-precise
2021-03-05T14:04:40.278630+1100 h0nk tag[3248]: hi

(-s causes logger to copy what it sent to stderr; -t tag changes the tag logger uses from my username to whatever name I specify; and -i adds a PID.) I note that systemd-journald parses and throws away the supplied timestamp and PID (if provided) and determines this information itself (which is why the PID is always present, and why I'm able to ask for milliseconds with short-iso-precise when none was provided):

# echo 'Jan  1 00:00:00 test[1234]: hi' | ncat -uU /dev/log

# journalctl -qn1
Mar  5 14:06:12 h0nk test[5593]: hi

# journalctl -qn1 -o short-iso-precise
2021-03-05T14:06:12.538712+1100 h0nk test: hi

From a security perspective this makes a lot of sense. **However**, I've found that if I even deviate *slightly* from the format of >

Mmm _d HH:MM:SS tagwithnospaces: message then everything goes sideways very quickly. It would seem that logger's --rfc5424 and --rfc3164 options are intended exclusively for connecting to syslog servers over UDP or TCP. Using these options when sending data to /dev/log produce disastrous results. RFC 5424 format (header defined in [section 6](https://www.rfc-editor.org/rfc/rfc5424#section-6)) blows up right from the get-go:

# logger -s --rfc5424 hi
1 2021-03-05T15:05:04.773304+11:00 h0nk i336 - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="648500"] hi

# journalctl -qn1 -o short-iso-precise
2021-03-05T15:05:04.773384+1100 h0nk logger: 1 2021-03-05T15:05:04.773304+11:00 h0nk i336 - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="648500"] hi

Curiously, while RFC 3164 format (header defined in [section 4.1.2](https://www.rfc-editor.org/rfc/rfc3164#section-4.1.2)) is largely similar to... whatever format logger uses *without* specifying an RFC option, even the addition of RFC 3164's hostname field is enough to break things:

# logger -s --rfc3164 hi
Mar  5 14:20:51 h0nk i336: hi

# journalctl -qn1 -o short-iso-precise
2021-03-05T14:20:51.638518+1100 h0nk unknown: h0nk i336: hi
                                     ^ O.o

**Side-question: I'm guessing the RFC formats preserve the leading `` priority field so that status information ("emergency", "critical", etc) is always transmitted correctly. Is this correct?** The date itself also seems to be a particularly sensitive value. Altering it even slightly instantly causes systemd-journald to regard the whole line as corrupted:

# echo 'Jan  1 00:00:00 test: hi' | ncat -uU /dev/log
               ^ two spaces
# journalctl -qn1 -o short-iso-precise
2021-03-05T14:17:04.484309+1100 h0nk test: hi

# echo 'Jan 1 00:00:00 test: hi' | ncat -uU /dev/log
               ^ one space
# journalctl -qn1 -o short-iso-precise
2021-03-05T14:06:23.414986+1100 h0nk ncat: Jan 1 00:00:00 test: hi

Interestingly, BusyBox's syslogd also carefully scrutinizes the date ([syslogd.c:829](https://github.com/mirror/busybox/blob/49fd1d69babc6945175068e8fe4c85713fe5fcdb/sysklogd/syslogd.c#L829)) , to the extent of making exact, hard-coded assumptions about where certain characters are:

/* Jan 18 00:11:22 msg... */
/* 01234567890123456 */
if (len >= 16 && msg == ' ' && msg == ' '
 && msg == ':' && msg == ':' && msg == ' '
) {

(Busybox syslogd also makes reference to the time being exactly 15 chars long in [L286](https://github.com/mirror/busybox/blob/49fd1d69babc6945175068e8fe4c85713fe5fcdb/sysklogd/syslogd.c#L286).) I'm fascinated by why the date seems to need to be specified so very carefully. I found glibc's implementation of syslog() ([syslog.c:223](https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/syslog.c;h=2cc63ef287a71fc6447774773adbffddaae514f3;hb=HEAD#l223)) insightful to study: - it uses the format "%h %e %T " - %h -> %b; %b = abbreviated month name according to locale - %e = day of month with leading space - %T = time like %H:%M:%S - the trailing space after the timestamp matches up (mind-numbingly exactingly) with BusyBox syslogd's msg == ' ' check (!) - it uses the (glibc-internal?) function strftime_l(), which (as noted in [time.h:101](https://sourceware.org/git/?p=glibc.git;a=blob;f=time/time.h;h=3bf206be0b92f92628fadf882e7e0e0412f646bb;hb=HEAD#l101)) , "*take[s] the information from the provided locale and not the global locale*"; strftime_l() here is passed _nl_C_locobj_ptr (defined in [locale.h:17](https://github.com/bminor/glibc/blob/be9b0b9a012780a403a266c90878efffb9a5f3ca/include/locale.h#L17)) , which is an internal pointer to _nl_C_locobj (defined in [xlocale.c:34](https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/locale/xlocale.c#L34)) an (also-internal) glibc-global reference to C locale definitions. logger uses different header-formatting functions depending on the mode it's called in: [syslog_rfc3164_header()](https://github.com/karelzak/util-linux/blob/f3a7b057ac28adaaf81c503abab2d8731cdc9b0c/misc-utils/logger.c#L544) , [syslog_rfc5424_header()](https://github.com/karelzak/util-linux/blob/f3a7b057ac28adaaf81c503abab2d8731cdc9b0c/misc-utils/logger.c#L766) , and [syslog_local_header()](https://github.com/karelzak/util-linux/blob/f3a7b057ac28adaaf81c503abab2d8731cdc9b0c/misc-utils/logger.c#L886) . The important part of syslog_local_header() is:

if (ctl->pid)
		snprintf(pid, sizeof(pid), "[%d]", ctl->pid);
...
xasprintf(&ctl->hdr, "%s %s%s: ", ctl->pri, rfc3164_current_time(),
		ctl->tag, pid);

*There's that format again.* Priority, time, tag, PID. [rfc3164_current_time()](https://github.com/karelzak/util-linux/blob/f3a7b057ac28adaaf81c503abab2d8731cdc9b0c/misc-utils/logger.c#L412) is a wrapper for gettimeofday() and localtime() that bundles a list of abbreviated English month names as a portable alternative to glibc's locale dance. Given the strong similarity in RFC 3164's date format to the dates used in the "local" "/dev/log format", it makes a lot of sense to reuse the date-formatting function. But significantly, this is the only thing that can be reused, as the "local" format as a whole is still distinct from the RFC 3164 format. **Question: What is the /dev/log format's provenance?** logger's "local" canonicalization is the closest I've been able to come to disambiguating the /dev/log format with a name distinct from the network/RFC formats. I've not found anywhere else that tries to name this distinction, it just uses it. I've not tested other syslog daemons (like rsyslog, syslog-ng, etc), and I don't know if they accept RFC-formatted lines of text over /dev/log, but given BusyBox's exactness, I wouldn't be surprised if this is some sort of violation... ...but at the same time, what standard or policy would define this behavior as a violation in the first place? I get the impression this is a standard "by convention", and that explicit ratification has been sidestepped due to the use of exactingly specific parsers in practice. Is this assumption correct? NB. I stumbled on [this great answer to the question of the significance of the /dev/log file itself](https://unix.stackexchange.com/questions/205883/understand-logging-in-linux/294206#294206) , which points out that applications running in chroots might send to a relative /dev/log path. This is a good point, and I use "the /dev/log format" very much for want of the right name to give it.

I was always a bit frustrated from the lack of characters in modern computer systems such as, from what I know: * A *global template literal character* for which the closest character today is a backtick (` ``) * A *global quote character*, for which the closest character today is a single quote mark (') or a double quote mark (") * A *global escaping character* for which the closest character today is backslash (\) * *A global line break character*, for which the closest character today is a LF or CR * Thinking about it, the entire regex language, on all its dialects, could have its own character system I personally believe that such characters could make computing more accessible and at least intuitively would like to experiment in working this way. I am aware that this would likely require to at least extend the QWERTY keyboard format and manufacture larger keyboards which I don't think will happen in the next 10 years, but I still want to ask on the **software side**: Is there an example for a shell or computing accessibility culture aspiring a (Unix like) shell with more special characters and if so what is it?
Since the dawn of Unix and Linux, was there ever a discourse/culture about such a thing? What's worth reading? At least a name of a concept.

I've just encounter the following question in *Unix Programming Environment*, the Kernighan and Pike's classic book on Unix (I found the below text on p. 79 of year 1984 edition, ISBN:0-13-937699-2): > **Exercise 3-6.** (Trick question) How do you get a / into a filename (i.e., a / that doesn't separate components of the path? I'be been working with Linux for years, both as end-user and programmer, but I cannot answer this question. There is *no way* to put slashes in filenames, it's absolutely forbidden by the kernel. You can patch your filesystem via block device access, or use similarly-looking characters from the Unicode, but those aren't solutions. I understand that Linux ≠ Unix, but the same principle should apply, since the system has to be able to unambiguously extract directory hierarchy from paths. Does somebody know, what exactly Kernighan and Pike thought about when asking this questions? What was the supposed answer? What exactly is the 'trick'? Or maybe original Unix system simply allowed to escape this slash somehow? **UPD:** I contacted Brian Kernighan about the question and that's what he replied: > The answer is (or was) “You can't.” Hence, Timothy Martin was right and gets the green tick.

Recently, I've been researching on the O_NONBLOCK feature specified in the standard. From what I've seen so far, the predecessor of this flag - O_NDELAY had existed all the way back to UNIX System III. I assume this is because was the only way to "poll" files for IO availability (poll and select didn't exist until the STREAMS and Sockets days). The standard developers chose to invent the O_NONBLOCK flag because it was deemed undesirable to conflict with the return-0-on-EOF semantic. Were there any programs that relied on O_NDELAY? I can think of text editors as one such kind of programs (because they may want to occasionally save backups), but were there others?

I have created a Unix System 7 VM in VirtualBox following instructions by Robert Nordier . I have dropped to the single user prompt (#). I can run commands like ls and passwd and cat. However, useradd is not found. Same is true for adduser. How do I add users in Unix System 7?

I wanted to write a small shell script for Linux and other UNIX systems (probably OSX). And also, why not keep things platform-independent out of principle, right? So I went with a #!/bin/sh shebang and one part of my script is supposed to compress a string so I thought I'd just have a look which is the POSIX default utility to compress strings or streams. Unsurprisingly, neither tar or gzip were listed at https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html . But what I did not expect: the listed compress was not installed on my Debian 11 Bullseye system! So I cannot even rely on POSIX commands being available on all so called POSIX-compliant systems? Did I make a mistake somewhere?

I am currently enrolled in a course that is teaching me UNIX fundamentals, such as common commands and such. After doing some digging on UNIX, I came across the rabbit hole of legal battles over who owns UNIX, and the UNIX wars. I have done some research, but the sources are sort of dated (circa 2003 - 2004) and have conflicting information as far as who owns it. Here are a couple of the sources I have found: https://www.zdnet.com/article/who-really-owns-unix/ - states that the Open Group owns it https://www.informit.com/articles/article.aspx?p=175171&seqNum=2 - states that the SCO owns it After reading these sources, it sounds like the Open Group is claiming to own the UNIX trademark, while the SCO claims to own the UNIX source code. Am I understanding that correctly?

UNOS is a derivative of UNIX by Charles River Information Systems. Google and Wikipedia doesn't have much information on it. Is there any version of it still in use?

Why does ed start at the last instead of first line of a file? Most of ed's behavior makes sense when you remember that it was for interacting with a printer, but not this. Since I believe it reads the whole file into memory, it's not even an IO seek thing.

I want to try old versions of UNIX for fun, but I don't know where to get them. Is there a way to download them?