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:
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.
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.
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 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.
>>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
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.
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.
Matching against both the current directory and the path when completing at the beginning of the line comes to mind.
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.
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!
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.
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/
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.
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.
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?
>>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.
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).
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 argSuperiority! 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.
>>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.