We’ve all used UNIX or one of its derivatives. A lot of us use it for development and server applications. Quite a few of us love it. And I’m sure we’ve all got things we hate about it too. Is it time for a new Unix-Hater’s Handbook?

I have a few bones to pick:
a) Inconsistent command-line options:
Most programs use -- in front of their options. For example, mc --version. Some don’t, like dd, find, and other utilities from the Stone Age.

(backward compatibility, blah, blah, blah, it’s been several decades, blah, blah, blah)

b) Directory structure:
Yes, we’ve all heard the reasons why there’s a /bin, /usr/bin, /usr/local/bin, and /usr/local/*/bin, or why there are multiple library locations, or why there’s a /usr and /usr/local, etc. So what?

And then there’s the programs that think they’re somehow special so their default installation location is something like /usr/local/mysql (cough). Or libraries that think they’re special (hello, Qt, I hate you with a passion).

The directory tree is a mess, no matter what the reasons given.

c) Libraries and binaries:
Related to the above, all the binaries and libraries are thrown into a huge pile. Take a look in /usr/lib. Do you know what every library in there does? What its dependencies are? And what about /usr/bin? Don’t forget /usr/local/lib and bin too! And what happens if you have different versions of a library in /usr/lib and /usr/local/lib? Fun!

Yes, in this era of shared libraries and commands accessible from everywhere (ie, ye olde PATH), that’s one solution. Yet, while DOS didn't have shared libraries, its layout was a whole lot simpler. Want to install a program? Put it in its own directory. Want to remove it? Delete directory.

It's not that hard to devise a solution that combines simplicity and consistency with shared libraries and programs. Where is it?

d) The shell:
Zsh/BASH/tcsh, etc, are all a lot better than the windows world. On the other hand, shell scripting is amazingly ugly. Why isn't the shell more extensible? Perl may not be an ideal language, but the perl shells I've seen were a lot saner when it came to making shell scripts. Oh, sh and friends also have a convoluted configuration system.

e) Configuration:
I love doing a ls -la of my homedir. ~90% of the crap I see there are dot files. It’s like every program thinks it has a god-given right to throw a file in there.

And then there are the ones that don’t put a dot file. Nor a dot dir. Nope, they put a _normal_directory there (hello GNUstep, zinf). So now not only is my –la listing full of junk, normal listings are too. Thanks guys.

Why can't they standardize on something like ~/.config/* ? At least then there'd be only one uninteresting entry clogging up the file listing. It’s not that hard to cd .config to get at my settings.

f) Init system:
So how do you like your poison? BSD or SysV? Do they treat you well at night too? Or are you one of the crack-heads who made your own custom init system that uses a makefile so you can parallelize you boot? That makefile’s pretty brittle, huh?

People are having flamewars and religious arguments over BSD and SysV, but they simply both suck (although SysV sucks more, hah!). Maybe Apple is right? I don’t know much about initd, but Apple has a point.

g) Editors:
The major editors are all terrible. Emacs is a monstrosity that required bizarre key-combinations. Vi has that horrible dual-mode (and also has byzantine sequences of keys). I prefer vi myself, and I know vim can remove the dual-mode, but why aren’t there any sane and powerful default editors out there?

h) Library, library, on the wall...:
Since I’m one of the strange people in this world who still downloads source tarball and compiles, I’ve noticed an odd trend: more and more programs are making useless libraries. The developers think it’d be brilliant to put all functionality in the library, and leave some tiny stub program in the binaries.

Of course, nobody ever uses that library other than the original proggie. So why did they make a library in the first place? You’re writing a program, not a library.

Linux-land, at least, has gone library mad. They make and use libraries like it’s air. Then there are the fools who make major pieces of software that require either KDE or Gnome to be installed. And eventually we end up with several pieces of software that use either.

Nah, we’re not using GTK or QT, we’re going all the way, baby!

Wait, I’m running two desktop environments now? At the same time? WHY?!

i) ZOMG FREEDOM!
Does h) sound familiar? Do you often hear the refrain, “but it’s freedom to do and use whatever you want! Evolution! Yayayayay lololol!”

Guess what? As a user I don’t give two hoots about your freedom. I want a system that works, and isn’t held together by cruft and duct-tape.

Guess what? As a developer I don’t care about your fucking freedom either. I want a single API to target (and isn’t held together by cruft and duct-tape)!

Why do I have to use an additional abstraction layer so I’ll be able to use either QT or GTK depending on what’s available?! And what’s the whole deal with autoconf?

If you had a free hand, what would you wish was changed? Do you disagree with me? Flame away and show me where I’m wrong.

-_-

s/initd/launchd/

Regarding a) and d), which I, in my madness, consider the same point - the command line environment as a whole:

I love command lines. Problem is, I grew up with AmigaOS, which had a shell and command-line utilities that were orders of magnitude more user-friendly than the Unix environment. People don't seem to realize the command line doesn't actually have to be an intensly user-hostile environment.

All Unix shells are stone-age remnants. As you said, the scripting can and should be offloaded onto other utilities that are better at it. They could also do a whole lot more to help out the user. I especially enjoy when I type the name of a directory in a shell, and it'll actually go to the trouble of inspecting it, and then sullenly declaring "foo is a directory." Yes, I know, I wanted to cd into it. Shells on other platforms have been doing that for decades when you typed the name of a directory.

The default commmand line on Windows is horrible, but 4DOS and its successor 4NT are lovely environments, that actually make work easier for the user. This is a fascinating concept that Unix shells should try.

Now, the command line flags. The AmigaOS had an OS function for reading them - it let you specify names for options, what kind of options the are (flags, strings, multiple strings...). It would also always list the options if you just put a "?" as the command line option. It would furthemore intelligently figure out when option names could be left out. It didn't use any dashes or slashes either. A copy command might have a command line template like: "FROM/M/A, TO/A". This means there was a "FROM" option that took multiple strings and was required, and a "TO" option that was required. So you could either say "copy from file1 file2 to directory", or just "copy file1 file2 directory", because it was clear from context what the options are. This is where Unix people would complain about "what if you had a file named FROM?", but of course this could easily be disambigued by saying "copy "FROM" directory". It was also up to programs, not shells, to expand wildcards, thus causing far less problems that way.

Regarding b) and c), Mac OS X has a fairly nice solution with its bundles. This is worth ripping off.

Regarding g), text editors in the rest of the world pretty much standardized how an editing interface should work, and what key combinations to use for the most important tasks (ctrl-s, ctrl-x, ctrl-c, ctrl-v, and so on) a decade or two ago. Unix text mode editors never seemed to notice.

OS X is also worth ripping off for e). ~/Library/Preferences and namespaced preference files all the way!

for b), c) and e) there's already gnustep, it just needs more widespread use/acceptance. how about abolishing kde/gnome and doing a second nextstep =o?

> [...] and then sullenly declaring "foo is a directory." [...]

zsh: set auto_cd

> 4DOS and its successor 4NT are lovely environments, that actually make work easier for the user

care to give some examples?

now, time for some serious disliking:
1) termcaps: this is what happens when you let people free reign over how to implement a terminal instead of putting a gun in their backs. i had to explicitly add the f11 and f12 keys to a termcap entry to be able to use them in ncurses apps. another thing that got me was that i had to write out escape-sequences in vim if wanted to use alt-<key> and friends. in case i ever
have to work on the console, i'll have to do this all over again. joy. maybe i'm just horribly stupid and overlooked an obvious solution. anyway, i use screen in urxvt (my favorite term) in utf-8 mode and sometimes encounter random glitches when displaying non-ascii chars, whereas it works just fine in xterm
and -- when not using screen -- in urxvt. screen seems to be using an arcane version of termcap internally, so putting up a correct terminfo doesn't help. just another victim of termcaps?

2) various aspects of x11:

• the pasteboard content vanishes as soon as the source application exits. RAHRG.
• copying and pasting between different gui toolkits or terminals more often than not produces garbled non-ascii chars. gah.
• some gui toolkits make use of xft, others don't.
• way too many gui toolkits that behave differently. x11's no-policies policy is to blame for that.
• xft is a pain to configure right.

3) ... i forgot.

btw: i want a "find" without hideous syntax and a "zsh" which understands utf-8. kthx.

> zsh: set auto_cd

An optional setting in an alternative shell nobody uses is a little bit more obscure than I'd prefer.

>> 4DOS and its successor 4NT are lovely environments, that actually make work easier for the user
>care to give some examples?

Well, apart from the fact that typing the name of a directory lets you cd into it, it also has tab completion that doesn't scream at you (What IS it with Unix and ctrl-g? It beeps at you at the slightest provocation. You pressed backspace, yet there's no character to delete! BEEP! You pressed tab and there are more than one matching file! BEEP! You pressed tab and there are no matching files! BEEP! I am hungry! BEEP!) and force you to repeatedly read file lists and find the next characters to write to continue the slow march towards getting a full filename. It also has a pseudo-graphical (curses-like) configuration system, so you can actually find and change options.

It still doesn't have default actions for non-executable files (so that I can just type "main.c" and it'll load it up in a text editor, or "yaranaika.jpg" and it'll open an image viewer. That's something I hacked together for myself on AmigaOS once back in the day, and it was mighty useful.

you should seriously try an alternative shell nobody uses. like zsh. it doesn't beep at you when you tell it to stfu, doesn't force you to painfully wade through filelists (every tab cycles through the list of matching files; is the output more than a screen full, you can scroll through all matches and even use the arrowkeys to select one. this can be a bit awkward to use unfortunately...) and even takes typos into account when completing. i hardly used any other shells but i find zsh's completion system to be utterly superior, though you have to meddle with the config a bit to get the desired effects. it comes with a sort-of setupscript for the completion system.

regarding default actions, why not assign a single letter a function or script? like:

function d {
 case $1 in 
  *.jpg) bla $1;;
  ...
 esac
}

shouldn't be too much typing overhead.

>>8

First off, it's not installed everywhere. That adds a huge barrier to use right there. I don't feel like downloading and compiling new software for every machine I use, especially not when I am not root. I'm sure it's good, but it doesn't save Unix from sucking because it's not part of the system most of the time.

And really, the last thing I need is to sit around trying to remember how to write cryptic statements like that. "esac"? Double semicolons? "*.jpg)"? This is just more o the stuff we already discussed how utterly badly it sucks.

Also, I tried "set auto_cd" on a computer that does have it installed, and it didn't work.

> OS X is also worth ripping off for e). ~/Library/Preferences and namespaced preference files all the way!

While I like the sound of that, I'd like to know why Library and Preferences are capitalized. That's another pet peeve of mine in *nix: most directories are all small, but a few start with caps. It makes typing the name out annoying (is this a problem with OSX too?). But this is a peeve of mine due to the following:

Do we really need case sensitivity? I like files having both upper- and lower-case names, but why must they be accessed with exactly the same case? Windows has fucked up its filename schema in other ways, but I quite like how I can access ThisIsAFile.txt as ThisIsAFile.txt, THISISAFILE.TXT, thisisafile.txt, etc...

Differentiating between File01a.txt and file01a.txt seems stupid. It certainly makes navigating the tree harder. Am I missing something?

>is this a problem with OSX too?

Yes and no, apparently. You can run commands on files with 'incorrect' capitalization, since the FS itself is case-insensitive, but bash refuses to tab-complete them.

>>9

> [...] remember how to write cryptic statements like that [...]

write a perlscript named "d", then and add it to somewhere in your PATH or make an alias.
... i'll stop here, i noticed that the solutions to the problems you point at are all hacks.

>>10
whoops. *setopt* auto_cd i mean.

Since we seem to have wandered into the realm of OSX vs Linux:

http://jwz.livejournal.com/494040.html

I can so sympathize with him.

You people are utterly clueless and while in itself that is highly irrelevant I fear that you will spread your idiotic misconceptions to a new generation and everything will be fucked up again so please, utilise the power of Shutgun Mouthwash on yourself.

>>15 is DQN

>>15 has convinced me of the errors of my ways and I will immediately install Lunix on both my Windows and Mac machines!

Oh, let me add another pet peeve: UNIX's default security model. Sure, it's simple, but you can't do much with it either. xrwxrwxrw my arse.

I started bumping up against that problem with the original IIchan. Groups just didn't cut it. Root being all-mighty didn't make me happy either. Fortunately, XFS supports ACLs.

It's kind of funny... remove everything that sucks about Unix, and you no longer have anything near Unix, remotely compatible with unix, or recognizable as Unix. Unix IS its flaws. Don't complain about the flaws of Unix, for you are complaining about the very essence of Unix itself.
Really, the problem is that Unix was implemented when the filesystem was king, while currently an information database would be preferable. If we were to retool every concept attached in any way to the Unix filesystem over the years (locks, queues, spools, rc files, init, cron, termcap, etc.) we would find we had a completely new OS, but probably a very good one.

Unix may be the sum of its architectural flaws, but the user interface flaws could very well be addressed without turning it into anything but a better Unix. Mac OS X is part of the way there already. Somebody really should take up where OS X left off.

>It still doesn't have default actions for non-executable files (so that I can just type "main.c" and it'll load it up in a text editor, or "yaranaika.jpg" and it'll open an image viewer.

That could make command completion annoying. However, OS X has an "open" command that does just what you want: open main.c opens the file in the associated application, open . opens a window for the current directory in the Finder, and so on.

>Differentiating between File01a.txt and file01a.txt seems stupid. It certainly makes navigating the tree harder. Am I missing something?

HFS+ (OS X file system) is traditionally case-insensitive (or rather, case-preserving), though it can optionally be case-sensitive. If you put "set completion-ignore-case on" in .inputrc, you can also get easy completion in bash. That is what I use.

Oops, some friendly fire when deleting crap. Apologies.

> That could make command completion annoying.

I don't see how. Tab and return are at opposite ends of the keyboard.

http://kylin.org.cn/

>>25
command completion and file completion are different the shell has to differentiate between it
the shell would not know to file complete if the file comes first

>>27

Is this problem really impossible to solve with the amount of computing resource available at the present time?

>>27
What does that have to do with opening a datafile by typing out its name? I'll admit they're related, but I still don't see the problem, particularly if people prepend a ./ to the name.

>>28
how is computing resources related to a logic problem?

>>29
prepending ./ to the name tells you that it is an executable and the shell file-completes an executable in the current directory

maybe some other character could be used to show that it is a file like !picture.png or something

>>30

Because many, many limitations in Unix are just remnants of designing for systems with a lot less resources, and therefore cutting corners. There are any numbers of solutions to this "problem" that only amount to adding a bit more code and intelligence to the tab completion.

>>31
any brilliant solutions?

Matching against both the current directory and the path when completing at the beginning of the line comes to mind.

>>33
and we come back to >>25

> That could make command completion annoying.

Why? You'd have a few more options than normal, is all.

I'd probably be safer if it ignores executables in the current directory, though.

>>35
I want my command complete to be the same whatever directory I am in. Otherwise I would have to command complete while keeping in my head the files that are in the current directory.

>>36

No, that's one of the biggest UNIX faggotries of all time. PUT THE CURRENT DIRECTORY BACK IN THE PATH ALREADY YOU GODDAMN HIPPIES! IT IS NOT BLOODY UNSAFE, YOU LOONS!

>>37

Why would you need to keep anything in your head? Well, except for the fact that tab completion in most Unix shells hates you?

Easy, friendly solution: When more than one file matches, pop up a list of options. It's not hard - the curses library has existed for what, three decades?

>>39
$ ls
perkele

$ cd perkele; ls
firefly.jpg

$ fire<Tab>

I want it to command-complete to firefox in both directories without popping up a list of options (unless there is a program starting with fire in the path).

>>40
That works for me.

$ mkdir perkele
$ cd perkele
$ touch firefly.jpg
$ touch qwert
$ chmod +x qwert
$ fire[tab]fox
$ qw[tab]ert

Last to lines completed via tab.

>>40

Why?

>>41

We're talking theoretical behaviour here, not something that shells actually do right now.

>>42

I'm used to it, I guess. I just like my files and executables seperate.

>>42
What's theoretical about it, when it does already exist? I'm not sure though, if that's they way bash does it by default, or whether this behaviour was triggered by this bash_completion thing, I use.

>>42
zomg. you touched, chmoded and executed files in an empty directory!

s/42/41/

>>43

The whole point was that the system would be much more powerful and efficient if they weren't.

BTW, some lines I added to /etc/inputrc that have somewhat saved my sanity in Bash:

set completion-ignore-case on
set bell-style none
set input-meta on
set output-meta on    
set show-all-if-ambiguous on
set visible-stats on

I also did something with match-hidden-files, although I don't remember whether it was on or off.

>>39
http://img143.imageshack.us/img143/7089/screenshot4do.png
Zsh "menu" let's you scroll and choose with arrows when there are multiple possibilities (I guess tab-completion has same behavior(?)) , works for files, hosts, usernames, parameters of actual command, env variables and possibely everything you ever wanted to tab complete on command line.

Also corrects upper/lower cases, typos based on some rules, ie completing file by r<tab> if there's only file beginning by t or m will commence completing the t... because of possible typo, well you get the idea.

Shells have great posibilities today. Sadly, most distros come with old sucking bash.

oops, tab-completion -> bash-completion (or whatever that extension is called)

Zsh always comes up in these discussions, but every time I try to use it, it doesn't do any of the wonderful stuff mentioned. It seems to really, really need a better default configuration. There's no use in having wonderful features if you go to great lengths to hide them from the users.

>>1
I can't believe how fucking right you are. Quoted for win. I agree on each and every one of your points.

The problems thus far highlighted for the Unix world can be summed up in an analogy I heard once. If operating systems were buildings...

A few people at the Bell Labs thinktank tried to develop the perfect operating system. The first steps, just like erecting a building, are putting up the scaffolding and inventing the needed tools that don't exist yet. But as it turned out, the tools and scaffolding had a fatal flaw: they became too useful and well-designed to be just temporary structures. As a result, the perfect operating system was never built, and what we have in its place are tools and scaffolding.

Hah, that's unusually apt.

apt-get install a_better_os

So far as a) goes, VMS also got this right, in addition to AmigaOS, in a somewhat similar fashion IIRC.

b) on your list is, I think, best handled in current linux distros by gobolinux. They toss out the normal unix directory structure in favor of old-school DOS like one-program a dir type system. I keep meaning to try it out, but am hooked on Ubuntu lately; perhaps when I get Xen setup I'll give it a whirl in a VM!

c) see b) !

d) ksh (real ksh, NOT pdksh) has much better extensibility, in fact it has hooks so you can add syntax!! It's now open source from att labs, so check it out if you want a better shell for scripting. I'm not sure how the default ksh set is for interactive use, I know that it can be turned into bash-equivalent friendliness for interactive use, but the vendors who've used it (Sun, IBM, I mean you!) have had really shitting interactive defaults for it. Not sure about the mothership att distro though. Apple shocked me by having a sane tcsh interactive environment for Terminal!

e) say it, brother!

f) I keep meaning to redo init in a capability-secure variant of Scheme!

g) yes, they do suck, no?

h) I'm in favor of static linking, along with placing things all in one dir like gobolinux does. Or at least stashing your dynamic libraries under your own dir hierarchy like you do in gobolinux (or apples Libraries/ dirs)

Cheers!

-djm

VMS got a lot of things right, particularly security-wise. It's one of those legendary operating systems that a lot of us younger ubergeeks would love to install and play with, but probably never will. Compaq just sits on OpenVMS and largely lets it rot.

The whole Xen and Microsoft story is quite sad too. I'd almost kill for something like Xen, but no Windows supports it on current CPUs. The ability to write and test both server and client software on the same machine at the same time? Wow!

Someone might point out I could do both on one OS, except that some tools I like only work in linux (mainly valgrind), while the client may be a closed-source windows binary. Using Wine is a crapshoot, and I'm not sure what to think of VMware.

>>56

Oh man, if there's one thing I want back from AmigaOS, it's ReadArgs(). Best function ever. That, and Datatypes. I can't believe it's the year 2005 and no major OS has an extensible framework for reading generic file types. Mac OS X has a perfect setup for creating that kind of thing, but instead they've just got their half-assed NSImage and NSSound objects.

How does ReadArgs() compare to getopt()? By the sound of >>4 it's a lot more interesting.

>>59

They're miles apart. First and foremost, any ReadArgs()-using program would automatically print out its argument template when invoked with "?" as the only argument. That way, there was always a standardized way to see what arguments a command takes. The template isn't the most readable thing, and if I re-implemented it, I would add some cleaning up to make it more readable, but the basic idea of a standardized way to print out the exact argument template is wonderful.

ReadArgs() also isn't anywhere near as anal as getopts() about argument order - there's no need to stuff every option before the filename (to the point that most unix commands require you to specify the output file BEFORE the input file, something that just makes no sense). Since all options are named, you can put them in any order. Only if you leave out the named identifiers does order become important. These would all be equivalent:

copy file.txt directory
copy from file.txt to directory
copy to directory from file.txt

>>1
Totally agree with that. Unfortunately, I doubt any one of them will be fixed ever. <3 unix beard

Very relevant: http://it.slashdot.org/comments.pl?sid=166174&cid=13863290

Ars Technica reviews MS' new command-line environment.

They've integrated scripting and command-line parsing much more tightly. The command-line parser is actually just evaluating expressions in their Perl/Python/Javascript-like language (with extensions to make it more a traditional command line). The commands also read arguments in a style reminescent of ReadArgs(), which makes me very happy (although I think they could do without the dashes everywhere). The syntax is a bit quirky at points, but nothing as bad as Unix shell scripting.

I'm undecided if this is a success or not, but it sure is lightyears ahead of Unix shells.

Heh, not exactly the right link, that. Here is the real one: http://arstechnica.com/guides/other/msh.ars

The one I originally posted should be amusing to Alpha Centauri players, though.

Hallelujah! Maybe someone will rip it off because it's teh evil M$!!1!

About bloody time. Anything is better than *nix shell scripting. It's the programming atrocity of the centu past three decades!

Even if they don't, maybe it could (and I know I've being incredibly naïve here) drive home the point that Unix shell scripting is incredibly primitive and behind the times, and inspire someone to create something better.

>>most unix commands require you to specify the output file BEFORE the input file, something that just makes no sense

Most unix programs require you to specify the output file only if you specifically don't want it on stdout; and most unix shells make it very easy to get stdout into a file, so you don't need to give the output file to the program, you can just tell the shell to redirect the program's output to the file. After the program. Problem solved.

blah -o outfile infile
blah infile > outfile

> Most unix programs require you to specify the output file only if you specifically don't want it on stdout

Incorrect, and even when it is correct, it's incredibly annoying, as you are likely to send binary data to your console, possibly screwing it up, or at least making a lot of noise.

That would be a bug in the program then. It should use the isatty(3) system call in order to avoid outputting binary data on a terminal. gzip for instance does this.

There are a few programs that will write binary data to a terminal if you explicitly specify stdout (they shouldn't), but I don't know of any that do so by default, with no options given.

There are lots that do. I don't know how many times I've had to start a new terminal thanks to some program spewing binary data into my console. The netpbm tools come to mind.

And this whole discussion is yet another example of how Unix is broken: It promotes behaviours that can easily be disruptive, without giving a mechanism to easily avoid the pitfalls, leaving it up to individual program authors to jump through every required (and non-obvious) hoop. In the end you can't blame every individual programmer for not learning the secret tricks, when the system should have provided easy-to-use mechanisms instead.

isatty(3) is hardly a secret trick. It's in POSIX and has a manpage just like everything else. It's no less obvious than any other system call, including open(2) or fopen(3). Are those hoops programmers have to jump through to open files, in your opinion?

>>69

list of programs that do this plz

I've never used NetPBM.

>>71
I've had cat do it to me numerous times.

>>72
That's your fault for using cat on a binary file. cat can't know if its input files are binary, unless it buffered and tried to guess. You can avoid this problem by running file(1) before you run cat(1) if there is any doubt about the file's nature.

On the other hand, gzip, netpbm and flac know that their output is always going to be binary.

Waah waah waah! It's all my fault! So terribly sorry, good sir, I promise never to do it again!

I mentioned that cat does this. Since someone wanted an example, there it is.

>>70

No, it's not a secret trick that you use "isatty()" to find out if something is a tty. It is a secret trick to know you're supposed to do this when outputting files to stdout, which as you say is a preferred method to do this. A decent system would offer more automated methods to perform such tasks, that hide the details from the programmer so he doesn't have to worry about it.

This doesn't mean there should be a function to combine fwrite() and isatty(), mind you, it means that outputting to the console by default is a retarded idea, especially when the console is designed to break if you do this (needless to say, this is also retarded in itself).

>>71

You think I keep a list?

But we're not talking about outputting to the console by default; we're talking about outputting to stdout by default. Yes, it's a standard principle of unix systems that stdout is usually attached to the terminal; and it's also a standard principle of unix systems that stdout is conveniently redirectable via IO redirection and pipes.

I can't believe that anyone who's used unix for more than 5 minutes doesn't just by default pipe things with unknown or variable-length output through a pager like more/less/most etc. (And if your pager blats binary output at your terminal: dude, your pager sucks.)

> I can't believe that anyone who's used unix for more than 5 minutes doesn't just by default pipe things with unknown or variable-length output through a pager like more/less/most etc.

We do, mate, we do. Contrary to what you may think, we're not clueless, and everything you've mentioned up until now is pretty obvious. This isn't about what can and cannot be done; this is about how to do it better than it's done now.

Never having used ReadArgs() I'm in no position to comment. However, WAHa has, and he thinks it's a lot better. So... how about you tell us why the current *nix nuttery is better than ReadArgs(), or at least why it isn't inferior in comparison?

This has just been a long and drawn out response to Waha's comment about needing to specify the output file before the input file. I was just saying that you rarely need to do it that way.

>>ReadArgs etc

Standardised argument parsing is a great idea. But when I look at the proliferation of getopt modules on CPAN I don't exactly feel confident that anyone is ever going to come up with a single way to do it that everyone is happy with. And if people don't like it, they will roll their own, which is exactly how the current *nix nuttery came about.

testing

Fuck you too, >>79.

> It still doesn't have default actions for non-executable files (so that I can just type "main.c" and it'll load it up in a text editor, or "yaranaika.jpg" and it'll open an image viewer.

Guess what I just stumbled upon on some ZSH fansite?

alias -s tex=vim
./a.tex
<vim starts up and displays the file>

And another thing..

autoload zmv
zmv '(*).bak' '$1'  # Removes '.bak' from all files that match the first arg

Superiority! Groar Now I want this to become something like that MSH. I propose ruby as the foundation~

Oh, you can leave out the ./.

alias -s de=$BROWSER
alias -s htm=$BROWSER
alias -s html=$BROWSER

$ heise.de
<opens in browser>
$ http://4-ch.net/manga/index.html
<opens in browser>

:O

I prefer ksh.

i like fish

That is neat, although of course it still uses horrible incomprehensible Unix syntax, but that's to be expected.

I could also make some comment about having to stumble across these things on some zsh fansite. Zsh seems to be horribly embarrassed about having features, and does its best to not let you know.

>>86
Actually, you can conduct extensive research on all it's features by reading the manpages, but for me, that's a clear case of 'tl;dr'.

>>87
What the fuck is tl;dr?

>>88
"Too long; didn't read". An appropriate comeback to RTFM.

>>89
Ohh, I always thought it was nonsensical, like "fgsfds". Thanks!

And totally agree with WAHa on zsh.

So I've read all this thread and agree with most of the UNIX-hate part, it looks like the proponents of the status quo are always replying that since they spent months of their lives learning about the intricacies of 70's software, everybody should, and if they complain, they just are not intelligent enough.
What UNIX needs to get outside of a server room or a nerd's basement is more vendors that give a big "fuck you" the UNIX way and customs.
But then I use OS X and launch applications using a mouse instad of terminal.app, so maybe I'm just too stupid.

nobody is forcing you idiots to use UNIX. don't like it? don't fucking use it.

What's wrong with noting the deficiencies and fixing them >>92?

PS. DQN is here: http://4-ch.net/dqn/

You're not fixing anything.

You're whining about a simple, coherent and powerful system because you're a whiner who can't create such a thing yourself.

> You're not fixing anything.

The first step to fixing is recognizing there's a problem.

> simple, coherent

Next up: goldfish are deadly.

> you're a whiner

You're in the wrong board. Trolls go here: http://dis.4chan.org/dis/

I shall try to adapt to the level of discussion here. Ahem.

*>>94, if you love Unix so much, why don't you marry it?*

> You're whining about a simple, coherent and powerful system

Looks like you haven't read a manpage in years.

>>81 and >>83
Super fricking awesome. ZSH forever!

>>95-97 are DQN

"The first step to fixing is recognizing there's a problem."

But you don't do anything about it. You just complain about the people who actually do stuff. If you think UNIX is so bad, show me a system you've made that works better. But you won't because whiners just remain whiners.

I'll expand a bit on this. UNIX is the best and most productive system I've used, and yes, coherent. It all fits together. It's sure not perfect, but the alternatives aren't forthcoming. The critics ITT haven't produced any.

This thread has left a bitter taste in my mouth because many of the criticisms are based on a lack of understanding, or a lack of willingness to understand. >>1 for instance complains about inconsistent command-line options, but nearly all UNIX utilities do use options consistently: they are one character and can be combined, so "-9qo -" is equivalent to "-9 -q -o -". The --long-option style was invented by GNU and has been copied by some applications. It is not at all the standard.

The directory structure >>1 complains about serves a good purpose and is not at all a mess. /bin is for utilities that are needed when the system is booted in single-user mode and the files under /usr may not be available. /usr/bin is for other system programs, and /usr/lib is for system libraries. /usr/local is where applications and application libraries go. These distinctions are important for maintaining servers and timesharing systems. If >>1 only wants a single-user desktop computer, then maybe this is overkill for >>1. I, however, find the /usr vs. /usr/local distinction helpful and the /bin vs. /usr/bin distinction quite livable, if a little superfluous. MySQL and Qt are not part of UNIX and are therefore moot, although if >>1 thinks they suck so much, he's welcome to fix them or make something better.

I can recognize more than half of the files in /usr/lib and have at least a vague idea what the others do. The same goes for /usr/local/lib. I do not know what everything in /usr/bin and /usr/local/bin is, but I can easily find out by typing "man commandname". I do not need to know about library dependencies, because anything in /usr/bin or /usr/lib is part of the operating system and I have no reason to change it, and my operating system supplies a package manager that tracks dependencies in /usr/local/bin and /usr/local/lib (although this is not a standardized part of UNIX).

If "it's not that hard to devise a solution that combines simplicity and consistency with shared libraries and programs," then indeed, >>1, where is it? Anything is easy if you're not the person who has to do it. I find the directory hierarchy simple and consistent enough already. That's not to say it couldn't possibly be improved upon, but you haven't suggested any improvements, and there are more important things to worry about. There is no real problem with the current layout.

The complaints about shell scripting are pointless. If >>1 prefers to write Perl scripts, then why doesn't he just do so? There is nothing different about the process, only that the line at the top has to say "#!/usr/bin/perl" rather than "#!/bin/sh".

The configuration complaint is similarly without merit. The entire reason ls hides dotfiles by default is not to show configuration files. If you don't want to see them, don't give ls the -a option. Then >>1 complains about GNUstep and Zinf saving configuration files visibly, not as dotfiles. This is a valid complaint against those programs, but like the MySQL and Qt examples, the problem lies with poor-quality applications, not UNIX.

It is easier to dismiss a system as worthless and badly designed than to learn to use it properly. But if you must do the former, at least don't make stupid threads, please. If you have something better, just release it, and stop complaining about what exists, okay?

>>100

• "My country has a very retarded government. I try to discuss the issues but I can't get my point across easily since my opinions are not widely shared."
• "But you don't do anything about it. You just complain about the people who actually do stuff. If you think your government is so bad, show me a country you've made that works better. But you won't because whiners just remain whiners."

>>102's very valid point aside, how about I show you a shell I made for AmigaOS once back in the day that was much more of a joy to work with than pretty much any Unix shell out there? Will that count?

(Excepting the theoretical possibility that I might one day figure out how to make zsh behave the way I want it to)

Also:

> This thread has left a bitter taste in my mouth because many of the criticisms are based on a lack of understanding, or a lack of willingness to understand.

I think you misspelled "unwillingness to agree with me" at the end there. Trust me, we've had the supposed justification explained to us many, many time, and we are not ignoring them out of some sort of pigheaded denial of the world around us, we actually disagree with them. You can not simply dismiss those who do not agree with you as uninformed or unwilling to learn. As it happens, both me and dmpk2k are, if I may make so bold a claim, highly skilled computer users and programmers. We have many, many years of experience using both Unix and non-Unix systems. It is from exactly this experience that we formulate our criticisms of Unix as it now stands.

I really don't have the time to refute all your points, especially as many of them are refuted here, or even in >>1. If you try to read the thread, you will also notice a criticism of the mindset of many Unix users and developers that there is nothing wrong with Unix, and any problems experienced is due to the person complaining. This is not only incredibly arrogant and irritating, it also not a good attitude for a developer to have, if he wants people to use his product.

> It's sure not perfect, but the alternatives aren't forthcoming.

a) It's not perfect.
b) There aren't any alternatives.
therefore
c) We shouldn't note the shortcomings?

Ignoring that b) is false, I'd really like to know what the hidden premise here is, because c) certainly doesn't follow from a) and b).

>>102, many individuals can write software by themselves. Few can overturn governments and/or start their own countries.

>>103, please do.

>>104, the original post contains many complaints that suggest the writer does not understand the mechanisms involved (see >>101 re: command-line options, directory layout, etc.). Argument from authority will not change this.

>>105. Alternatives. Present some then. VMS? DOS? AmigaOS? Those are all dead. Unix has some deficiencies, but not what you've "noted" -- your notes are the same old whiny rants about how "I don't understand it, therefore it sucks."

> many individuals can write software by themselves. Few can overturn governments and/or start their own countries.

How many write operating systems by themselves? You're just parroting the number one fallacy of the Internet: "If you can't do better, you're not allowed to critize!" Do you never complain about food if you can't make something better? Do you never critize art, music or architecture?

> the original post contains many complaints that suggest the writer does not understand the mechanisms involved

Look, I am trying to tell you: Both him and me do understand. We just do not agree. Try to accept that there is a difference. If you would read >>1 again:

> Yes, we’ve all heard the reasons why there’s a /bin, /usr/bin, /usr/local/bin, and /usr/local/*/bin, or why there are multiple library locations, or why there’s a /usr and /usr/local, etc. So what?

And again: "Yes, we’ve all heard the reasons..." - why then are you repeating them, as if being told them one more time would suddenly make them valid?

For instance: The reason you give for the split between /bin/ and /usr/bin/ is completely invalid on just about every modern Unix system. Modern Unixes, especially those running as a home desktop, are never booted into single-user mode, and if they are, /usr/ is pretty much always available. There is no longer any need for this, yet it is still vehemently defended as a good design decision. That is the attitude we're annoyed by.

>>107 It sure is difficult to drag logic into a debate where so much is at stake for the status quo camp, they don't want to realize that their extensive knowledge of trivia about legacy UNIX quirks would become useless with some clean-up.

I hate all the mystique the UNIX hackers like to have around their OS.

A lot of valuable time is wasted all the time by people who try to learn their way around issues that should have been solved before half of us were born.

Let's all just move to Plan 9. :-)

> Present some then.

Off the top of my head, used commercially: OSX, Windows, QNX, OpenVMS, TRON.

> "I don't understand it, therefore it sucks."

I understand it all too well, mate. Just because you say I don't doesn't make it true. But, if it protects you emotional investment, you'll believe that regardless.

By the way, you still haven't told me what the hidden premise in >>105 is.

>>107, you could at least suggest an alternative design, e.g. instead of doing this, the system should work this way. Write a detailed specification for how the entire system should work and justify why each part of it is best off working the way it does. If you don't want to do that, or are not willing, then maybe you'd best not be commenting on the shortcomings of existing systems. The number one fallacy here is "My ideas are great, and I can just leave the easy part of actually doing something with them to other people." Nobody's going to come along and fix Unix for you because you whined and ranted about it.

>>110: OSX is Unix. Windows -- glad your sense of humor is still there. QNX is a real-time operating system, so it's not suited to the same purposes as Unix. Besides, a quick visit to Wikipedia informs me that it is "POSIX compliant" and "Unix-like." Not familiar enough with your last two examples to comment -- but if they're so good, why aren't you using them, instead of griping about Unix? This is a serious question.

>>111
I thought that this thread was already the spec. You take UNIX and you correct what has been stated to be wrong.
And people may actually take steps to fix UNIX if enough people are pissed off at its current state. Somebody comes up with the idea, somebody with the work. I have seen my share of interesting projets started that way from discussion.
But you know, you really shouldn't expect people to design or develop a complete operating system to make a point in an Internet discussion.

And you cannot say that OS X is UNIX because it is not perceived as such by normal users (by normal users, I mean people who only use terminal.app when coding). It is not a pretty GUI on the top of a standard UNIX, it is UNIX reworked until you could integrate it into Mac OS.

> OSX is Unix.

So... if I mention the mess of libraries that plague *nix, then I'm misguided because that isn't UNIX, but if I mention OSX, all of a sudden it is? You defend against many of my criticisms, yet when OSX attempts to fix those same problems you want to take credit for that?

> Windows -- glad your sense of humor is still there.

I favour pragmatism. I try to use the best tool for the job, and for some things Windows is that tool. Are you saying that there's nothing Windows is better at?

> QNX is a real-time operating system, so it's not suited to the same purposes as Unix.

Why no, it isn't, although the embedded folks would be interested to hear that. Mind you, QNX isn't too bad as a general *nix replacement either. Ever used it for desktop?

But we weren't discussing specific domains. We were discussing flaws with *nix. Just because *nix makes a good server doesn't mean that it has no problems. So the directory hierarchy is ugly, what does that have to do with it serving webpages?

>>111

Nobody's going to use my own personal spec either, and neither should they, because it wouldn't be very good. I'm not an operating system designer, nor does everyone have the same requirements as me. That's why we have discussion first to get people interested in the idea, to indentify problems, and to suggest improvements. Such as this very thread.

Are you seriously suggesting that every single person who has problems with Unix should make up their own design before they are allowed to even talk about it?

>>112
Unfortunately, nobody seems to be correcting anything ITT, just complaining.

I don't expect anyone to design an operating system to make a point, but surely in order for a better operating system to exist.

>>113 is DQN. The "mess of libraries" is an application issue -- third time I've had to say this. I'm not defending KDE or GNOME. And operating systems that serve a different purpose are not alternatives -- should be obvious, right?

>>114
Certainly anyone should have given serious thought to a better design before they begin to talk about it with your sort of attitude: "It's not me, it's Unix." If you believe the root of the problem is Unix being flawed, you should be ready to suggest a system design that isn't.

If what you people are trying to say is that Unix is not ideal for desktop systems with GUIs, I agree. Moreover, for that application, I think it should be replaced, not fixed.

>>115

> The "mess of libraries" is an application issue -- third time I've had to say this.

And M$ Windows has DLL-hell, amirite?

It looks like I have to spell this out for you:

• If OSX is a *nix, the only real difference is applications and libraries.
• Once you strip away all the libraries and applications, it probably isn't *nix. Let me guess, diff and bash aren't applications?
• Modern *nix systems come with those libraries and apps installed, because the OS alone is useless. Hello?

> And operating systems that serve a different purpose are not alternatives

Why not? Why isn't Windows an alternative? Why not QNX? Why not all the others? It's only an alternative if it's in an problem domain where UNIX is superior, right? The fact that people are trying to push linux embedded (where QNX and TRON make their daily bread) have nothing to do with this, right?

And again, what does this have to do with anything? Even if *nix was the only solution, and no others existed, does that mean the ugliness vanishes? That somehow the directory hierarchy improves itself, there are fewer inconsistencies everywhere, the commonly installed shells magically suck less, and the library mess fixes itself? *nix is somehow suddenly perfect?

> If you believe the root of the problem is Unix being flawed, you should be ready to suggest a system design that isn't.

One of my professors at uni is an old-skool OS developer (now retired) who happens to like Solaris. When I ask him about the problems with initd, all I get is a bunch of handwaving. He is unable to give me a single reason why initd is better than launchd, other than something along the lines of, "it's missing the magic".

The problem is that the *nix of today evolved that way. Normally I'd applaud that, but now there's cruft in there that's several decades old. Even parts that were there in the initial design could use replacement, but they're still there because of inertia (the same reason the linux fanatics always gripe that Windows is still here).

When better solutions comes along, what happens? They're ignored due to dogma and familiarity.

You're right to some degree about good ideas being ignored. Fortunately, though, there are enough Unices out there that at least one of them generally implements any particular good idea.

I'm thinking of strlcpy and strlcat, for instance, which are now available pretty much everywhere except on Linux.

Another way of looking at it: Steve McConnell, in his book "Code Complete", introduces the idea of a "technology wave": if you're on the early end of the wave, you're working with new technologies that are exciting but still developing, and you may not have very mature tools. On the late end of the wave, your tools are hardened, battle-tested, but consist mostly of thoroughly crusty technology.

Unix is very late-wave now. For me this is a good thing, because having a solid, carefully put together operating system is important to me. It does mean some aspects look a bit quaint (e.g. /bin vs. /usr/bin is rarely a useful distinction anymore), but not so much that I can't be productive.

Now, Microsoft's "monad shell" is an interesting idea. I haven't used it, but examples I've heard give me the flavor; for instance when you type "ls", instead of having text thrown at you, you see objects, which have properties and can be manipulated. I'll be the first to admit that seems quite a bit more powerful than cut, paste, find, and xargs. But this is real early-wave stuff, so for the moment, it's only interesting to experiment with, not to use on a daily basis.

I don't think any major improvements will be made to Unix. All you'd end up with would be an incompatible Unix, and who wants to use that? I think the next big system architecture will have to start from scratch. It also won't be written in C. When C is your systems language, Unix is probably about the best you can do. The next kind of system will use, and popularize, a more higher-level language, like Lisp, Haskell, or who knows what.

> The next kind of system will use, and popularize, a more higher-level language, like Lisp, Haskell, or who knows what.

and will probably require 2GB of RAM to run well (Windows Vista, anyone?)

There used to be computers that ran everything with lisp (see: lisp machines).

Some commercial lisp compilers can come close to C, as can certain dialects of ML. Given the additional leverage you're getting from higher level languages, it would almost certainly be a worthwhile tradeoff.

>>120
Actually, I swear Microsoft wrote most of Vista in Haskell. Not only would it totally explain the astronomical memory requirements, it also might explain the rumors that they've finally built a secure OS this time. (There are no buffer overflows in Haskell programs.)

>> (There are no buffer overflows in Haskell programs.)

I bet MS could find a way

No, they really couldn't! Haskell is referentially transparent and purely functional. There's no such thing as a pointer in it.

I suppose they could mess up and have a buffer overflow inside part of the Haskell run-time system, though.

after finally looking at plan 9, i have to say it looks like it could be a very nice system if it had better graphics capabilities and more apps ported to it...

I think it's pretty safe to assume that if your language can't have a buffer overflow, you can't code an OS in it either. Part of an OS, sure, but not the whole thing.

>>126
I meant the vast majority of it. You can at least code all of userland in such a language, and probably parts of the kernel.

Also, 0x80GET!

>>125
Get to work.

>>117
That's typical behaviour from Solaris fans. Deride everything until it appears in Solaris, then claim ground-breaking and revolutionary. I have to constantly put up with them; they spend years bashing features in other OSes not in Solaris, then magically when Solaris gets a piss poor copy of them (under a different name, naturally), the bitches won't stop extolling the virtues of it and claiming how it's the first of its kind. e.g. DTrace, just a weak copy of perf counters.

> DTrace, just a weak copy of perf counters.

Hahaha, what?

>>130
Sounds like the cdrecord guy; apparently, Solaris is the gold standard of SCSI device handling, and other OSes require so much ostensibly horrible hackery to get working that he'd rather not deal with them unless they're "reasonably close" to what Solaris does. The comments bashing Linux in the libscg source are particularly telling (and they only got worse after his little hissy fit on linux-kernel).

Not only that, but "libscg" insists on viewing things through the guise of a Unix workstation circa 1992 (e.g. a SPARCstation IPX or SS1); it demands a SCSI bus:target:LUN address and will freak out at you if you hand it a device node. (It may still work, but it still bitches you out.) This, of course, makes ittle sense if you're trying to burn to a non-SCSI device (you could argue that anything that speaks SCSI is subject to the SCSI Parallel Interface rules, but not even SCSI-2 or CAM says that, and Windows certainly doesn't do it that way), and I haven't seen a new SCSI CD writer in years (only the very first DVD recorders were SCSI, not that cdrecord will support them without getting "ProDVD"...).

Someone at SuSE patched the warning about this out of their version of cdrecord, and he screamed and yelled about it on linux-kernel until they told him to go away. (He does the same thing on the Debian bug tracking system whenever someone does something "inofficial" with cdrtools...god damn annoying, that). I find that behavior childish and unprofessional, and would like to see cdrecord replaced because of it. I've considered doing it myself, using some patches I made up to FreeBSD's burncd program for another project, but I just haven't given myself the time to write SCSI support layers for other OSes and clean it up.

The directory structure can be fixed, take a look at heretix(http://www.h-e-r-e-t-i-x.org/, a new linux distrobation, everything is written in ruby(the init system too). The package manager installs everything into /pkg with a name system based on the package name and version. For example GCC 3.4 is installed as /pkg/gcc/3.4/. Then it's symlinked into /bin, /lib and so forth.

At the moment it uses WhiteWater(a bittorrent like protocol) for distrobation. But a change to a new protocol is expected with the next stable release.

Sure there are som problems with their implentation but it is a change for the better and imho the road that alot of distros will take.

>>133
That sounds like a half-done version of GoboLinux.
http://www.gobolinux.org/

"Distrobation" is my new favourite nonsense word.

Why the emphasis on it being written in Ruby? That's hardly noteworthy.

>>133
I salute those trying to escape the FHS piece of shit. Whoever thought of FHS, we need to have that motherfucker killed.

>>135
It rhymes with masturbation

>>137
I looked up FHS on Wikipedia. It seems to be a fairly new standard that everyone ignores in the first place, based on the article. I suspect you meant to trash on the de-facto standards that preceded FHS (/etc, /bin, /sbin, /usr/bin and so on).

>>134
GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.

>>136
Easily extended init system.

>>135
Embrace it.

>>137
FHS is just de facto heir with ugly /opt added to it.

>>138
It is better then the windows way of doing things, it was created before the thought of dependency handling :).

>GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.

So if different FS layout and init system don't qualify as "new", what exactly is remarkable about heretix? The portage clone in Ruby?

> Easily extended init system.

i don't know ruby.
learning ruby is a decidedly nontrivial task.
therefore i suggest you refrain from using the word "Easily" next time.

> GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.

This statement makes no sense.

Problem: File system is badly structured.
Attempted solution: Changing the names of stuff to arrange it better.
Complaint: Changing names does nothing new.

what

>>141 is right on. If it's supposed to be easy, it should be possible to do it in my choice of language.

If it's supposed to be easy, it shouldn't be using a "language" at all.

"It's possible to program a computer in English. It's also possible to make an airplane controlled by reins and spurs." -- John McCarthy

>>138
Yes, I meant the guys who came up with that shit. Didn't know FHS was new, I thought I just had found a name for the source of all evil.

>>139

> GoboLinux is doing stupid things, like adding capital letters to the begining of names.

Capital letters aren't stupid. They look better. For example, see the menu on the left here in 4-ch. If it were all lowercase, it'd look like a GNU hippie's job.

> It is better then the windows way of doing things

Ha ha, no.>>139
Capital letters aren't stupid. They look better. For example, see the menu on the left here in 4-ch. If it were all lowercase, it'd look like a GNU hippie's job.

Capital letters are stupid for path names because you have to mash the shift key all the time.

Capital letters are good... if you have a case-insensitive filesystem (sup NTFS)

Capital letters and spaces in filenames are good. It is much more conveninent for users. Who cares about developers? Those guys are clever enough to use the space, backslash, and tab key when they have no other choice than to use the CLI.

>>149 but it's much less convenient for users who prefer the CLI.

>>150
And your point is? Why should we cater to the needs of the minority? That's because of this attitude that we still have impossible to understand folders like /bin, /usr, /dev, /etc. Compare for example with Applications, Library, System.
Is it because some people can get some sense of superiority by pretending that the CLI is much better suited to normal file management (as opposed to complex operations that require a scripting language)?

>>148 has another good point: Dump the goddamn case sensitivity from the Unix filesystem. That's a horrible, horrible idea.

...that is, case sensitivity is a horrible idea. I was being somewhat unclear there. Case sensitivity is really just boneheaded programmer mentality.

>>147
That's because you have a filesystem that's case sensitive even though we treat lowercase and uppercase letters conceptually the same.

>>149-150
We can also use a case-insensitive command line subsystem, like Win32's.

>>152-153
I wholeheartedly agree with you, and I'm a programmer.

However, for some reason, case-sensitivty seems to be a quite religious issue for some Linux people. Even when they need to support case-insensitive anything, they make sure that case-sensitivty is default and to enable insensitivity you need to use some ugly, long, or half hidden switch the like of --really-i-want-case-insensitivity-please-ok-i-suck-i-know-sorry . Even the CRT pseudostandard functions are longer (strcasecmp as opposed to stricmp in most other CRTs). It's as if they wanted to punish people for wanting case-insensitivity.

I mean they rename /bin and so forth into /Programs and what not, no additions nor changes.

sure if you don't know ruby there is a problem but make your own distro then :P.

>>151 is the reason democracy doesn't work.

>>151
Seriously, how do you come up with this garbage? "Sense of superiority"? "Pretending"? I:

• type fairly quickly;
• have poor hand-eye coordination (i.e. can't use a mouse);
• find fixed-width fonts easier on my eyes than variable-width.

Is it so hard to believe that someone has these characteristics, and therefore prefers a different method of interacting with computers than you?

But yeah, obviously I inconvenience myself in order to get a "sense of superiority", and gays make a conscious choice to be perverts, and the minority doesn't matter. And 2 plus 2 is five. And ignorance is strength.

Seriously, "sense of superiority"? What the fuck, man?

>>154
You can't blame Linux for strcasecmp(): it was introduced in 4.4BSD. Personally, I think that the added obviousness of what the function does outweighs the need to type 3 more characters when using it. What runtimes besides MSVC's call it "stricmp", by the way?

>>157
A lot of people force themselves to use the CLI to be "cool". Go to any web-based Linux forum to see for yourself. Your case doesn't refute >>151.

However, it's true that visual file managers should be more suited to keyboard command and that the current ones lack some of the advantages of the CLI. (I think GUI FMs are better since I work mostly with media and scripting languages, but let's not go off-topic).

So, anyway, can't we at least all agree that UNIX folders suck? Their meaning is hard to guess and every program and library chooses where to install its stuff seemingly at random.

I fucking hate coding. This thread has convinced me to quit my job writing code, move to brazil and start killing people for a living.

>>159

And no, unix folders don't suck. If you follow standard conventions for building your application it's real fucking easy. It's been the same way for how many years now? Figure it out. And why the hell do you have to instantly be able to tell what each folder does. Do you know how much more complicated an application would be if you wrote everything out in plain english?

>So, anyway, can't we at least all agree that UNIX folders suck? Their meaning is hard to guess and every program and library chooses where to install its stuff seemingly at random.

man 7 hier

anyone who doesn't obey that deserves to be beaten, stabbed, tarred and feathered, shot, boiled in oil, and burned at the stake.

>>162

Yes, that's hierarchy is seemingly random. So basically you and >>161 seem to be saying that it doesn't matter if it makes sense or is usable, it should be this way because it has always been that way.

Just what is it with Unix users and all this dogma?

>>163
how is it "seemingly random"? it makes sense to me...
unless the linux hier(7) manpage is significantly different from the freebsd one i'm looking at right now...

EXPLANATION ABOUT "EASILY GUESSABLE"
If you need to learn about it, it is not easily guessable.

Examples: /bin, /etc, /usr (= user?), /opt, `/dev (= development?), ....
Counterexamples: /home, /binaries, /Applications, /libraries, /devices, ....

It's been there for 30 years? Big fucking deal. If the folders were named /fo, /pk, /cnf, /wut, or /lol, you'd cope the same way, by learning. It means that hundreds of valuable hours are wasted every time an UNIX newbie must learn about it.

Thank you for your attention.

> Do you know how much more complicated an application would be if you wrote everything out in plain english?

Yeah, let's just do everything in ASM!

>>165
Off the top of my head:
/bin - system binaries for single-user mode
/dev - devices
/etc - system configuration files
/usr/bin - system binaries
/usr/lib - system libraries
/usr/share - read-only system program data
/usr/local/bin - application binaries
/usr/local/lib - application libraries
/usr/local/share - read-only application data
/home - user directories

If it takes you "hundreds of valuable hours" to remember the above, you have issues.

>>167
You fail at reading comprehension.

• A small amount of time is lost by hundred of people. And directories names is the tip of the iceberg.
• You also proved my point: you have to learn this. Of course people can remember arbirtrary crap. My room is filled by printouts of cheatlists for a dozen technologies.

People should deal with as little learning as possible, and it is possible to do so without making the system less performant for developers and professional users. UNIX directory structure is a decent example of making other people deal with your problems because you didn't take the time to engineer your way around it.

If your are a coder, laziness is not just a virtue, it is a moral imperative. Computers are supposed to allow you to do stuff fast. Having to learn things gets in the way. One clever person is generally enough to solve a problem for millions of people.

I think the subtle mix of maximal computer performance orientation, legacy, elitism and coder mentality will never allow any improvement in UNIX, there's too much inertia.

I like how the original UNIX scheme doesn't try to hide the fact that it is an arbitrary set of directories, which is dependent on application developers to use properly.

>>169
Is this supposed to be a sarcasm? Given the UNIX fanboyism found ITT, it's difficult to say.

>>168 Unix is for people who don't mind learning. If you are not one of these people, don't use it. It's that simple.

>>171 You say that like it's a good thing instead of a problem that needs to be corrected.

> Counterexamples: /home, /binaries, /Applications, /libraries, /devices, ....

what's the difference between /binaries and /Applications?
no matter what, you're going to have to learn a few arbitrary things. i think it's obvious what /bin, /etc, /lib, etc. are for, and /lib is a lot shorter to type than /libraries...
also, no matter what the "correct" filesystem hierarchy is, it's still up to application developers to use it.

>>173 Then what about making them /b, /d, /h, /e, /r, /p, /t, /u, /v ? It'd save much typing.

>>173

OS X doesn't have /Binaries, even though I wish it would. But if it had, the difference would be that /Applications contains application bundles, which are essentially directories that contain all the files an application need, but are treated as single objects by the GUI - you click on it, and your app runs. You move it somewhere else, and all the files move along with it, and it still works no matter where you put it. /Applications is just for convenience. /Binaries would contain single executables that are run from the command line. (Right now, OS X has /bin and /usr/bin, but not /usr/local/bin unless you go and specifically create it, or some installer still stuck in Unix land creates it for you.)

PS: How often do you actually type "/bin"? And does your command line not have filename completion?

> How often do you actually type "/bin"?

about 5-6 times a day.

> And does your command line not have filename completion?

it does, but my text editor doesn't.

>>177 Mine does. Get another if it is useful for you.
And when you code, you generally don't have to type paths often anyway, since you don't hardcode them.

>>178
what text editor do you use?

>you generally don't have to type paths often anyway, since you don't hardcode them.

#!/bin/sh

Yeah, "#!/bin/sh" is another really stupid Unixism that should be changed. Why on earth won't it search the path? Why do I have to worry about whether Perl lives at /usr/bin/perl or /usr/local/bin/perl?

#! /usr/bin/env perl

>>179
TextMate, a great OS X only editor, but forget that, I realized afterwards that the feature is not built-in, it just completes words it already knows without caring about their semantics. Since it has a great shell integration, you can make a shell script to do it for you then map it to a shortcut.
I'm sure the filename completion should be possible in a lot of Unix editors though, maybe built-in in the feature-packed ones like emacs.

>>180
Not really knowledgeable about it, but shouldn't /usr/bin/env perl work everywhere ?

>>181
Damn, you were faster

> emacs

is full of AIDS.
turns out elvis (what i've recently started using) does have filename completion, it just isn't enabled by default...
apparently pico also has filename completion, but all i've been able to find about that is that "-e" (what!) enables it.

Most GTK apps have filename completion.

Well, that was before GTK went gay and started removing text fields wherever possible. What's up with that?

>>184

Hooray for Unix feature shyness!

>>186
Don't you realize that they'll just go all "compatibility with the original 1975 freeware" then all RTFM, and the whole argument will start again in a slighlty different version?

>>187
Fork your own version then, damn. Or use nano. Or fork your own version of nano, if they're the same way.

Seriously -- you're a programmer. Maintaining a text editor for your own use is not that hard.

Ok, now I've lost track of who's trolling, who's sarcastic, and who's serious in this thread. Whichever it is, I'm nominating this for funniest line of the thread:

> Seriously -- you're a programmer. Maintaining a text editor for your own use is not that hard.

Looks like the argument for pretty much always follows this template:

• WTF does this weird UNIX behavior?
• lol RTFM, you're too stupid to know about it
• No, I actually know about it, but it'd be nice if it didn't bite ever beginner's ass
• Then if your remember it what is the problem?
• I shouldn't have to care about this stuff or remember it's here
• It already was this way before you were born
• But before I was born, computers were much differents, and the tradeoffs behind engineering decisions were different from today
• But if we changed it, UNIX would be much less powerful
• No, here's an idea of implementation that would keep it powerful
• It wouldn't be backwards-compatible
• Here's an idea of implementation that would allow legacy software to rely on the gotcha
• It'd be less performant
• CPUs and RAM are cheap
• What about realtime embedded enterprise-grade servers?
• Have different versions, one in ASM without any useful feature, and another one that isn't user-hostile? Isn't what that free open-source thing's about?
• You're all talk, but why don't you just fix it yourself? THAT is what that free open-source thing is about.

Cue quote from TAOUP, that one about UNIX being the sum of its errors, or one from K&R or Don Knuth if you really need to win the argument.

>>189
Seriously. It is not that hard. Download the source, grep it for "getopt", find the flag that gets set when 'e' is found as an argument, set that flag by default, and compile, and you're done.

Do you really think these guys who maintain text editors are doing something magical? How much dumber than them can you possibly be that you can't maintain a text editor?

>>189
Seriously. It is not that hard. Download the source, grep it for "getopt", find the flag that gets set when 'e' is found as an argument, set that flag by default, and compile, and you're done.

Do you really think these guys who maintain text editors are doing something magical? How much dumber than them can you possibly be that you can't maintain a text editor?

>>190 More like:

• Here's a whine about a problem I have no intention of fixing.
• Uh, to "fix" that would defeat the whole point. Do you understand what you're talking about?
• Yes, I understand perfectly, but {aspect of Unix, particular editor, etc} sucks because <describe personal gripe here>.
• That's because it's not designed for what you're using it for. Use something different.
• (proceed to write a ranty, incoherent rebuttal of an argument nobody was making)

Unix is not user-friendly. Get over it. Use something else if you can't accept the fact that power requires learning.

> Seriously. It is not that hard. Download the source, grep it for "getopt", find the flag that gets set when 'e' is found as an argument, set that flag by default, and compile, and you're done.

is now the funniest line of the thread.

> Use something else if you can't accept the fact that power requires learning.

That argument is used to justify requiring from users to take care of developer's problems.

also, MOAR LIEK:
- UNIX is perfect. If you disagree you are dumb, lazy, and mistaken.

> Unix is not user-friendly. Get over it. Use something else if you can't accept the fact that power requires learning.

I can't see this as anything but an admission that the complaints in this thread are all pretty much justified.

> I can't see this as anything but an admission that the complaints in this thread are all pretty much justified.

Next logical step is the good old "then fix it yourself instead of whining"

>>195 We're going in circles here. Why must Unix be user-friendly? You want something user-friendly, so why do you not use something that is? I don't get it.

I can see four possibilities here:

1. You are responding to the Linux zealots who think everyone ought to use Unix, typically coated with layers of tape and makeup. Very well, I think these people are being dumb too, nor am I satisfied with KDE/Qt/GNOME/GTK/etc. I think trying to build this kind of thing out of Unix is dumb. So if you're arguing this, you can stop because we agree.
2. You think that any operating system lacking in user-friendliness is not useful at all. This is trivially false because I use Unix and like it as it is.
3. You think that any operating system lacking in user-friendliness is only useful to people who are dumb, inferior, etc. OK, great, but why keep posting on /code/ just to essentially bash a group of people?
4. You feel that you and others are forced to use Unix (e.g. to run a server), and so it should be made easier for you. But why not hire a sysadmin or call for more diversity in general?

> Why must Unix be user-friendly?

Because it isn't opposed to being powerful or performant, in the same way that being user-hostile isn't always powerful and performant

1. No, 2. Yes, 3. No, 4. Sometimes

What we are is:

5. OS X users who think "lol, don't they notice how backwards their system is? Good thing I managed to limit my interactions with UNIX to that little web server which I never log into"

>>198
That was number 3.

200GET.

>>199
Not exactly.

How about that we would like to use Unix, but it's doing its best to make our lives miserable, for reasons that make very little sense?

> You are responding to the Linux zealots who think everyone ought to use Unix, typically coated with layers of tape and makeup. Very well, I think these people are being dumb too, nor am I satisfied with KDE/Qt/GNOME/GTK/etc. I think trying to build this kind of thing out of Unix is dumb. So if you're arguing this, you can stop because we agree.

This is part of it. However, OS X has pretty much achived making a user-friendly system out of Unix. It can be done, with great results. Apple haven't done everything mentioned in here, because they've mostly focused on the interface, but the point is: There's no reason Unix has to be unfriendly.

> You feel that you and others are forced to use Unix (e.g. to run a server), and so it should be made easier for you. But why not hire a sysadmin or call for more diversity in general?

There is also this, but come on, your suggestion there is incredibly silly. Are you really suggesting hobbyists "hire a sysadmin"? Hell, I do some admin work for 4-ch. Do you really think "hire a sysadmin" is a reasonable option here? "More diversity in general" makes no sense, when no other OS comes close to Unix for running a server.

>>1
funniest thing i've read all week

i would like to point out that xfce, rox, graveman, and xpad put their configs in ~/.config/. probably more, too

> OS X has pretty much achived making a user-friendly system out of Unix. It can be done, with great results. Apple haven't done everything mentioned in here, because they've mostly focused on the interface, but the point is: There's no reason Unix has to be unfriendly.

I like how Apple's propaganda calls UNIX in OS X: "BSD Subsystem". Although OS X technically works on top of UNIX, unless you work with very, very low level stuff, then for all intents and purposes, you can pretend that UNIX is just another useful app/lib thing in the system. For non-programmers, UNIX is just that weird user-hostile Terminal.app

> no other OS comes close to Unix for running a server.

If you are an hobbyist, OS X can be enough in some cases.

> This is part of it. However, OS X has pretty much achived making a user-friendly system out of Unix.

That's rather subjective, but nonetheless, not a conversation I'm interested in, nor do I see why it belongs on /code/. Programming has little in common with interface design.

> "More diversity in general" makes no sense, when no other OS comes close to Unix for running a server.

Well, that was kind of the point. Unix is the only choice on servers => there's no diversity.

> This is part of it. However, OS X has pretty much achived making a user-friendly system out of Unix.

That's rather subjective, but nonetheless, not a conversation I'm interested in, nor do I see why it belongs on /code/. Programming has little in common with interface design.

> "More diversity in general" makes no sense, when no other OS comes close to Unix for running a server.

Well, that was kind of the point. Only one choice on servers => no diversity.

>>203
if you are a hobbyist, windows 98 can be enough. i used it for years.

.config/ is a silly idea. It doesn't help organize anything because there's no reason for dotfiles in your home directory to be anything but configuration and other program-generated files. It's not an accurate name because dotfiles are used for other purposes: .w3m has cached pages and my bookmarks file in it, .bsflite has IRC logs.. It'd just be more typing for no reason.

> It doesn't help organize anything because there's no reason for dotfiles in your home directory to be anything but configuration and other program-generated files.

I've reread that several times, and I'm still uncertain what you're trying to say. Could you please rephrase?

> Programming has little in common with interface design.

is now the funniest line in all thread, and a good insight into the UNIX mentality

> .config/ is a silly idea. It doesn't help organize anything because there's no reason for dotfiles in your home directory to be anything but configuration and other program-generated files.

No. Dotfiles can also be backups and temporary files for your own use (faster than /tmp). And it helps organizing stuff. But what about using Config/ instead of .config/ ? After all, it is something important and useful, exposing it would be a nice idea, then it'd contain one subfolder for every app, maybe in reverse-dns notation to do it really clean.
Oh, wait, it's already been fixed, as usual, by OS X.

>>208
What dotfiles in your home directory would not go in .config?

>>210, see >>209. Mostly backups.

> If you are an hobbyist, OS X can be enough in some cases.

If you use OS X for a server (remotely, at least), you're really just using plain old Unix. There's no significant difference.

> Well, that was kind of the point. Unix is the only choice on servers => there's no diversity.

Right. But then what does "promote diversity" mean? Going around saying, "boy, I wish there were more server OSes"? Writing my own OS?

>>212
Sure. You're already going around saying "Boy, I wish Unix was more to my liking", aren't you? Why would going around wishing for something else be less effective?

> There's no significant difference.

Push butan. Receive server up.

> But then what does "promote diversity" mean?

Plan9 and GNU/Hurd, of course!!

>>213

Because cleaning up Unix is marginally less of a pipe dream than someone suddenly creating a whole new OS with widespread support?

Or, I guess, Windows stopping sucking as a server OS. I really can't even imagine what the odds of that are.

> Plan9 and GNU/Hurd, of course!!

"GNU/Hurd" was a good joke to throw in, but unfortunately it doesn't quite work since that's just more Unix anyway.

>>215
GNU is not unix!

>>216
That's a hacker joke that really means "GNU is a clone of Unix", but good try.

>>216,217 GJ at ruining the joke by explaining it!

I knew someone would take that bait... I just didn't think they would be that retarded. I like this 56ker ID. I should get another modem and shotgun them for the AMAZING SPEED.

m

>>219

KAMI!

>>219
It was so unfunny I figured you were just confused. Next time you want to make a joke, try being funny.

I always thought Hurd was a good idea. Particularly when you think of its clustering potential. Keep your kernel small and its dependancies minimal. Everything else can live in user space.

>>222
It IS funny though. GNU means GNU's not UNIX. Thus the proper response to calling GNU just like UNIX is to say that GNU's not UNIX.

>>223
Why wait? Use QNX instead!

Talking about which, I just discovered that QNX was bought out in 2004. Ouch.

UNIX is not user-friendly. But windows or macos X aren't either. Computers aren't for mouth-breathers regardless of what billy h. gates farts out of his upper orifice.

Today's catch:
_It doesn't have to be this way. Lisp programmers, for example, rarely write command line parsers because they can simply use S-expressions and use the Lisp reader to parse them. Moreover, Lisp programmers rarely have to learn new command line syntaxes for the same reason. S-expressions are a universal command-line syntax. Everything can be expressed as an S-expression.

Contrast this state of affairs with the unix command line syntax (or lack thereof). Because there is no universal syntax, the unix world is a Babel of dozens of different syntactic conventions. For example, sometimes the '-' sign is an operator (subtraction), sometimes it is a keyword indicator (the conventional command syntax), sometimes it indicates a function call (in conditionals in some shells), sometimes it denotes a range (e.g. in some regular expression syntaxes), etc. etc. etc. In lisp '-' has no special syntactic meaning. It is merely a constituent character like the letters of the alphabet._

>>2

• your *board still* **sucks,** __*NIGGER*__

>>2

• your *board still* **sucks,** __*NIGGER*__

>>2

• your board still sucks, __*NIGGER*__

>>2

• your board still sucks, __ NIGGER __

>>2

1. • your board still sucks, __ NIGGER __

>>2

1. • your board still sucks, __ NIGGER __
   • sucks,
2. • __ NIGGER __

>>2

1. • your board still
   • sucks,
2. • NIGGER

>>2

1. • your board still
     - sucks,
2. • NIGGER

>>2

1. • your board still
     sucks,
2. • NIGGER

>>2

1. • your board still
   • 1. sucks,
2. • NIGGER

>>2

1. • your board still
   • 1. _fucking
   • 2. sucks,
2. • NIGGER

>>2

1. • your board still
   • 1. _fucking_
   • 2. sucks,
2. • NIGGER

>>2

1. • your board still
   • 1. **fucking**
   • 2. sucks,
2. • NIGGER

`multline
code`

`multline \
code`

multline 
code

ugh make a new thread if you want to continue >>1's topic

command line needs to die, this is the graphical user interface age