In defense of Unix

http://leancrew.com/all-this/2016/03/in-defense-of-unix/

by ingve • 10 years ago

110 185 10 years ago

knz42• 10 years ago

The article could have been enhanced by highlighting that some shells (e.g. zsh) provide expansion patterns that recurse into subdirectories. e.g.

   ls **/*.txt

nothrabannosir• 10 years ago

or in bash, with the globstar option set:

    shopt -s globstar # e.g. in your .bashrc

    ls **/*.txt

mnarayan01• 10 years ago

It's probably worth noting that the option is new in 4.0 -- relevant as OSX users are likely on 3.0.

microcolonel• 10 years ago

In fish at least, I'd just use

        ls **.txt

escherize• 10 years ago

Thanks for the tip!

zokier• 10 years ago

In my opinion ls is one of the more broken bits in unix. But besides that, arguably more unixy way (even if no proper UNIX supports it out of the box) to solve is recursive wildcard, i.e.

    ls **/*.txt

twic• 10 years ago

I'd say this is less unixy, because it relies on the shell to walk the file tree, rather than delegating to a utility whose job is to do just that.

No comment on whether it's actually better or worse, mind!

OJFord4• 10 years ago

I was going to make a similar argument, but then I lost faith in what ls' job is, if we want to walk this really pedantic path.

After all, `echo * * / * ` is going to give you an ugly dump of space-separated files; while `ls * * / * ` will give you a pretty list with colours, ownership, permissions, date modified, is directory/exec/symlink, etc. with their respective flags or according to your alias.

I don't think it's cheating to argue that `ls` job is to format the files given, or within given directory.

Edit: Although possibly it is, because `man ls` tells us "list directory contents".

julian-klode4• 10 years ago

bash supports that, just do

  shopt -s globstar

to enable it.

DiabloD32• 10 years ago

A lot of what this article talks about is why systems like msys2 exists: to bring a *nixy command line to Windows.

bitwize2• 10 years ago

Only useful for compiling software that depends on Unix toolchains.

Modern Windows has PowerShell, which is leagues ahead of bash in terms of functionality and power.

DiabloD32• 10 years ago

Not really. I use msys2 every day, and I've never used it to compile things.

And PowerShell is kind of useless since I can't use it on any other computer I interact with on a daily basis.

I use a github-synced environment, that includes things such as my zsh and vim configs.

Gratsby2• 10 years ago

    function dir(){
      #make the windows guy happy 
      find ./ -type f -name "$1"
    }

yrro11• 10 years ago

But... there's already a dir command...

https://www.gnu.org/software/coreutils/manual/html_node/dir-...

Gratsby2• 10 years ago

hrmph. I never knew about it.

txutxu• 10 years ago

The post linked from this article says:

    Great. It is spread everywhere this kind of complication for everyday tasks. Want to install something, need to type:
    apt-get install something
    
    Since we only use apt-get for installing stuff, why not?
    apt-get something

I will give a response I didn't see in any comment there, in the original post, neither in this post or here:

Because it could fail miserably trying to install like this, any package named like a subcommand.

    apt-get remove     # is installing package remove?
                       # or is failing the remove subcmd without args

You can workaround that, by apt-get install remove in that case, but the error at first try is counter-intuitive.

Edit: fix my last example

phillc73• 10 years ago

Agreeing with you.

  apt-get purge
  apt-get autoremove
  apt-get update
  apt-get dist-upgrade

Plenty of other uses for apt-get besides install.

r0muald• 10 years ago

Furthermore, current versions of Debian/Ubuntu have the newer

apt

command

JelteF2• 10 years ago

This has actually been made a lot easier. You can now just use:

    apt install something
    apt remove something
    apt search something

instead of

    apt-get install something
    apt-get remove something
    apt-cache search something

The new apt command also has a progress bar. So I've started using it exclusively now instead of the different apt-x commands.

seanp2k22• 10 years ago

Link to docs for that? Not seeing it on the Debian or Ubuntu sites

https://www.debian.org/doc/manuals/debian-handbook/apt.en.ht...

The Ubuntu 16.04 docs mention using "aptitude install" but the official docs still mention "apt-get install":

https://help.ubuntu.com/16.04/installation-guide/amd64/apds0...

https://help.ubuntu.com/12.04/serverguide/apt-get.html

agumonkey2• 10 years ago

It's the start button story again. <get> + <remove> is absurd somehow. And longer. For discovery and ergonomics, all this should be facaded under sys or deb.

    deb install
    deb remove
    deb search | info
    ...

dpkg is still on point, it's less about system integration, and more about archives themselves.

julian-klode4• 10 years ago

Just use apt.

apt install

apt remove

apt search

apt update

etc.

yrro11• 10 years ago

For some reason, “Since we only use apt-get for installing stuff, why not? apt-get something” really pushes my buttons.

Perhaps I'm reading too much of my own biases into my interpretation, but this sounds like it's written by a developer who has only ever used apt to blindly install a list of packages in a Dockerfile, rather than someone who has any system administration experience.

And that's fine, except that maybe they should have taken two seconds to read the apt-get manual, and realise that apt doesn't just _install_ packages, but it also, shockingly, allows for them to be removed and upgraded too...

Now I've gotten that off my chest, perhaps a more favourable interpretation would be that they are trying to say that they would prefer separate 'apt-get', 'apt-remove', 'apt-search' commands, in which case they'd have a point. Fortunately there is now a new 'apt' command that can perform the most common operations that users commonly invoke via the apt-get and apt-cache commands.

nunobrito6• 10 years ago

Nuno Brito, original post author.

Sorry to disappoint but professionally administrating Linux machines since 2004, started as end-user in 1998 and I work with whatever machines are available. My apologies if the blog post is read as an attack on apt-get, this is not the case.

It is just an example. Not saying that we can/should change apt-get, there was apt already made for that purpose. This example is only to raise attention for upcoming command line tools and respective authors to think about the most frequent use-case scenarios and then make them as straightforward as humanly possible.

nunobrito6• 10 years ago

Original post author here, Nuno Brito

Except that exists no package named "remove" available today in mainstream Linux.. So we are forcing every single user across decades to use "install" because a "remove" package is prophesied and we couldn't reserve this keyword. Well, that's XKCD material.. :-)

But without playing: If you see the current syntax as good enough, that is OK. The point is usability on upcoming command line tools.

talideon• 10 years ago

You'd just be replacing one inconsistency with another: you couldn't use any command names as package names or the reverse without some kind of special case, which would be just as bad.

The real solution would be to get rid of the split between apt-get, apt-cache, &c., which is a real UI issue, and just use a single 'apt' command. Then you'd have 'apt install package' - two of the usability issues with 'apt-get' go away if you do that: the need to use a bunch of other tools for no good reason and the '-get' wart at the end.

And guess what: that happened in Debian and its derivatives a fair while ago. It's just that nobody made a big deal of it. Here's the relevant section of the handbook: https://debian-handbook.info/browse/stable/sect.apt-get.html

exprx• 10 years ago

The mentioned blog post is horribly ignorant, and lacks almost any valid points.

find, in particular, very much has a fine UI, and I dare you to process, and not just list, the files with cmd.

jstimpfle2• 10 years ago

I do like find's UI as well.

As an aside, I remember reading an article about how "the original Unix guys" found the syntax somewhat odd when find came about. But the command was useful enough that they kept it.

(The article was about how inconsistent the Unix commands are regarding syntax, and I think its conclusion was that it is much more important to design syntax to fit the problem than to maintain a superficial consistency with other commands).

Amezarak• 10 years ago

find, in particular, very much has a fine UI, and I dare you to process, and not just list, the files with cmd.

I'm not really sure why he is comparing find with cmd in the first place. Nobody thinks cmd is good; most anybody actually doing anything in a shell on Windows would be doing it in Powershell.

In that case, I would do something like:

Get-ChildItem pathname -Filter test.txt -Recurse

Any processing I want to do is easy, because I'm getting back objects and not just text. Say that I want to get a hash of each file named test.txt.

Get-ChildItem C:\Users\Amezarak -Filter test.txt -Recurse | Get-FileHash

ygra5• 10 years ago

    for /r "C:\some path" %F in (*.exe) do process "%F"

forfiles also exists, which works similar to find regarding passing the list of files to another command.

rat873• 10 years ago

ls -Recurse -Include "*exe" $PATH | % { something $_}

nunobrito6• 10 years ago

Nuno Brito, blog post author here.

Let's make a little test. You pick ten Linux users on the next FOSDEM and ask them how to find a file on a subfolder. This will be called the "brito test".

If only 2 people don't know the answer, you are correct and simplifying the command line is not really needed.

If 5 of them don't know how do it, they will be branded as "horribly ignorant" Linux users.

If 8 of those people fail, we keep closing our eyes and repeating that everything is OK.

If 10 out of 10 people that you ask are failing this question. Well, time to ask another 10 until you get a positive ratio of non-horribly-ignorant answers.. ;-)

And btw, the blog is about design of future (upcoming) command line tools and not about changing "ls" or any of the other example given. For example, thinking about the most used function of a tool and making that as simple as possible to reach.

raldu• 10 years ago

I cannot see how this article is defending UNIX only by talking about a single utility. It could be a better "defense" if it mentioned, for example, the power of being able to compositionally combine various commands through pipes, each of which doing one thing well. Inputs and outputs, remember?

The post the author is responding to is uninformed, and seems rather like a rant. DOS vs UNIX comparison does not work. I couldn't know how to take the `apt-get` example seriously. Because you could easily fix something like `alias ai='sudo apt-get install'` to achieve `ai something` magic with something as simple as aliases, which DOS does not even provide.

bpye• 10 years ago

Powershell also has pipes, and works with objects rather than with text. It can be very powerful and much easier than having to use awk, sed, etc.

iLemming• 10 years ago

and in the last example he given, i think you don't have to wrap things in quotation marks if alias done like this:

   alias lsr='find . -name $1'

jstimpfle2• 10 years ago

That doesn't work the way you think. Aliases don't receive arguments. The $1 will be expanded to the first positional argument of the surrounding environment when you call the alias -- not the first argument of the alias invocation.

pdkl954• 10 years ago

As jstimpfle mentioned, that doesn't work, which is why the argument is left off the alias. In general, you can do that in a function instead of an alias:

    lsr() {
        find . -name "$1"
    }

Wrapping variable expansion with double quotes is a good habit, so spaces are handled properly.

Also, if you are using a modern-ish bash, you almost always want to use "$@" when there could be multiple arguments. The double-quoted @ special variable is guaranteed to always expand as multiple args, but with spaces handled correctly:

    foo() {
        bar --quux=42 "$@"
    }

    foo "a b c" "Spaces in my filename.txt"

Vieira• 10 years ago

Ask your parents or non-geek friends: Given the task of finding the files with the name ending with .txt which of the following two commands would you choose?

  find -name "*.txt"

  dir *.txt /s

tonyedgecombe• 10 years ago

Neither, they would search in Finder or Explorer.

agumonkey2• 10 years ago

It's funny how minds differ. As a kid I was mesmerized by globbing and pipe operators. GUIs didn't have the same magic appeal. The List monad was calling me from the future past.

DanBC• 10 years ago

How about if you just give them the man page for "find" and the /? page for "dir" and see who can get the command correct first?

mc808• 10 years ago

Looks like "find" is yet another command with the Examples section at the very bottom. I suppose that's the convention or something, but sometimes I do run into a man page with the examples at the top, and it takes a lot of effort not to jump up and shout "Thank you!" loud enough for the author to hear me.

The brain is a powerful inference engine. A few well-chosen examples can teach 95% of normal people 95% of what they need to know (numbers pulled out of my butt, 2016). Put good examples at the top and marvel at how many more people actually seem like they RTFM.

hasenj3• 10 years ago

I actually do this instead:

    find . | grep "\.txt$"

rejap• 10 years ago

once you mentioned it, the original commands which are compared are not equivalent. Dir does case insensitive search, find is case sensitive. The equivalent would be:

  find . | grep -i "\.txt$"

vacri3• 10 years ago

And if we're going to be using the commandline, I'd much rather the unixy

    find PATH -name FOO

than the powershelly

    Get-ChildItem -Path PATH -Filter FOO -Recurse

I mean "dir FOO /s" is simple and all, but powershell was created because cmd was deficient in many areas.

The blogpost referenced in the article is also stacking the deck a bit, as some of the 'complex' commands are normal commands, but with the verbosity turned up - the rsync command has three flags for increasing verbosity...

Ao7bei3s8• 10 years ago

On the other hand, the power shell version returns objects that can be manipulated in a safe way, whereas the find version relies on "-exec" being a feature of find (Talk about bloat.), which is string-based (if you're not extra careful: breaks with spaces/tabs/newlines/semicolons/dollars/backslahes/... depending on what you use it for) and spawns one process per file (really inefficient).

rat873• 10 years ago

    ls -Recurse -Filter FOO PATH

ygra5• 10 years ago

    ls -r PATH FOO

if you want things to be short. Since parameters can be often given positionally instead of named and you can shorten parameters as long as they remain unambiguous and there are aliases – it seems like you're stacking the deck a bit as well.

PowerShell has over cmd (and WSH):

- Consistency in command handling, naming and discoverablity

- A robust scripting language

- A modern shell

- An embeddable scripting environment (most GUI configuration stuff on Windows Server these days is PowerShell in the background; PowerShell is also the NuGet console in VS)

- Extensible

- The core of the language is built up from mostly orthogonal commands which work completely the same regardless of the context

- Interoperable with native commands, .NET, COM, WMI, arbitrary item hierarchies (file systems, registry, etc. – comes back to consistency and the point above)

- SSH-like capabilities built-in. Running a command or a series of commands over hundreds of machines is no harder than doing it locally.

The (perceived) verbosity can usually be tamed quite a bit with aliases and shortening parameters (or using them positionally), which is what you'd do most of the time when working with the shell once familiar with it. I guess you're not yet familiar with PowerShell or never used it, and that's okay. Because the long commands are in many, many cases self-describing to the point that you don't have to guess at all what they mean or do. This also helps with learning or communicating with others.

13of40• 10 years ago

powershell was created because cmd was deficient in many areas

And we didn't just copy bash, because bash was deficient in many areas.

jkot• 10 years ago

I dont think its fair to mention DOS in 2016. There is PowerShell, VBS scripting etc...

catnaroek• 10 years ago

There are good things about the Unix shell, but the fact that the shell, not the program being called, expands wildcards, ain't one of them.

yrro11• 10 years ago

I like consistent and predictable rules for how wildcard arguments are expanded. There's no way that thousands of programs would all get it right if it were up to the developers themselves!

That said, it would perhaps have been nice if glob expansion would have, in some other timeline, been performed by a separate command, so that «echo 🞳» would print out a literal 🞳 character, and «glob echo 🞳🞳» would print out the result of the expansion.

glob could then accept flags to modify the rules for expansion, such as enabling the common shortcut for recursive expansion, rather than the user having to modify the behaviour of wildcard expansions by setting global variables.

alkonaut6• 10 years ago

This. I can't understand why it's handled at the shell level rather than at either the OS level (some Api to expand) or as a separate system tool?

What happens if I make a shell that does expansion slightly diffrently to the existing shells? That can't work well? So there is already a set of rules for expansion and all shells must implement them exactly? That does sound just slightly better than the apps trying to do the same thing?

jjnoakes• 10 years ago

Do you think the programs themselves should do the rest too? Tilde expansion? Quoting and escaping arguments? Word splitting? Variable substitution? Etc?

I would go mad working in such an environment.

thisisdumbski• 10 years ago

Seriously? I can't think of anything more pointless.

shocks• 10 years ago

Trying to improve our command line interfaces is not pointless.

zenlot• 10 years ago

After opening the link I expected to see an article from 90s, unfortunately it's from 2016... I can't believe that people still going into such debates.

Ao7bei3s8• 10 years ago

Not all of us were around (as admins) in the 90s.

If it was bad then, and it still (after 20 years) hasn't improved, then what do you expect?

nunobrito6• 10 years ago

The original article is about thinking on the end-user when designing new command line tools.

Yet the replies seem to focus on why the current "ls" works so well. Ironically, very few can ever find a file on a subfolder without first googling for the syntax.. :-/

IshKebab• 10 years ago

The complexity of the `find` command is the least of Unix's problems. How about defending these?

1. Unnecessary and confusing directory structure. `/etc`? Why not `/config`? `/usr` instead of `/system`, `/var` instead of ... well who knows. The maximum directory name length is no longer 3 characters.

2. Programs are mushed together and scattered through the filesystem rather than stored in separate locations. This basically means applications are install-only. Yeah, package managers try to keep track of everything, but that is just hacking around the problem, and most developers don't want to spend hours creating 5 different distro packages.

3. Not strictly Unix, but the mess of glibc with respect to ABI compatibility, static linking, etc. is ridiculous. Musl fixes most of this fortunately.

4. Emphasis on text-based configuration files. This is often ok, but it does make it hard to integrate with GUI tools, hence the lack of them.

5. Emphasis on shell scripts. Fortunately this is starting to change, but doing everything with shell scripts is terribly bug-prone and fragile.

6. X11. 'nuff said about that. When is Wayland going to be ready again?

7. General bugginess. I know stuff works 90% of the time, but that 10% is infuriating. Windows is a lot more reliable than Linux at having things "just work" these days.

kachnuv_ocasek• 10 years ago

it does make it hard to integrate with GUI tools, hence the lack of them.

I don't understand this point. Care to explain, please?

hasenj3• 10 years ago

My guess is that GUI tools often clobber configuration files once they touch them, because it's easier to write code that stores configuration as a hashmap and when it saves it back, the output is not going to preserve things like, user comments, the order of things, etc.

ygra5• 10 years ago

I guess they mean that because GUI tools often have, well, a GUI to change options, they tend to write their configuration files. Whereas for command-line tools it's rare that they provide methods for changing their options and thus they tend to only read their config, thus never running into the problem of clobbering user edits.

Mind you, there are plenty of GUI applications that get this right anyway. But usually for the vast majority of users there is never a need of mangling configuration files by other means.

sz4kerto2• 10 years ago

The answer for most of these: legacy. Changing all these is very hard, as it'd be difficult to change the \ to / under Windows, etc.

douche2• 10 years ago

Where does using / in paths rather than \ not work in Windows? Sorry to pick on your example, but from what I can see, they've already done that.

pdkl954• 10 years ago

Respecting legacy decisions is very important. Often in software design there are many ways to do the same thing. Unless there is an important reason to favor one of the possibilities, the correct answer is almost always to pick the legacy version.

Comparability is important, and not just for existing tools. Choosing something different has a learning cost, and if you have to care about both versions you have ongoing mental effort costs as well.

There may be better names for "/etc", but it's not worth the effort.

ZoF• 10 years ago

Windows is a lot more reliable than Linux at having things "just work" these days.

Ha, I'm server tech at a hosting company and this is spit-take worthy.

I really can't see how anyone could possibly think this.

Unless you're talking end-users local PC's this is wrong, and even then it generally isn't 'Linux bugginess' it's 'user ineptness'

digi_owl6• 10 years ago

Indeed.

http://www.computerworld.com/article/2467082/data-center/lon...

alkonaut6• 10 years ago

The two are completely different, and "just works" is definitely Windows strong side on the desktop.

On my desktop system I want apps installed in isolated directories, with few or no central dependencies. Even if it means I have some unpatched vulnerability in 10 places.

For a server system I don't mind having to tinker, and central libraries can even be a security win.

yrro11• 10 years ago

Some comments on some of your questions:

1. Legacy and convention. Why do my 64-bit system files live in C:\Windows\system32? Why is the first volume on my system C and not A? Why are there multiple 'global' window stations on my system? Why is the real path to my disk drive \GLOBAL??\PhysicalDrive0, but for some reason I have to use a different path (\\.\PhysicalDrive0) in my programs or else it won't work; a path that I can't discover by myself but have to be told to use by scouring the darkest depths of MSDN? What the heck is ipv6-literal.net and why do I have to refer to some weird third-party domain to connect to a file share on IPv6 within my own network? Making these changes would be disruptive for the software that has to make the change, and impossible for the software that can not be modified. Distributions exist that try to improve the hierarchy (GoboLinux) but no one adopted them. We're currently seeing a push to unify the / and /usr hierarchies, so at least in the future things will get a bit simpler here.

2. Legacy and convention. In the days when storage was scarce, you could keep the contents of /usr/share and /usr/lib on central file servers; a single export for the former could serve all your clients, and you'd only need a single instance of the latter for each architecture in use, rather than having a separate copy on each machine. Besides, even in a world where each program lives in its own directory, as soon as you want one program to install a component for the other to consume, you have to bring in a package manager to remember the fact that /app/A installed a plugin into the /App/B/Plug-Ins directory... not to mention the unusably long PATH environment variable that would result... I find the package manager approach is overall superior to unreproducible the crap-fest you get when applications arbitrarily dump files all over the system.

3. Perhaps I'm in the minority, but I've never had problems relying on glibc via dynamic linking; you just have to build against the oldest version that you want to support, which is a bit of a pain but it's hardly the end of the world. The tradeoff with musl is, that you can no longer rely on dynamically loaded NSS and gconf modules. If you don't need these, fine, knock yourself out--but you should be aware of the tradeoffs when you switch your libc implementation out; namely that you can no longer use mdns, myhostname, ipv6literal, winbind, LDAP, etc. for looking up hosts, users, groups and so on.

4. System-wide configuration is better kept in text form where it can be read by a human, contain comments, and be kept in Git. Desktop programs can store their config in dconf, or otherwise do whatever they want as long as it lives in ~/.config and I don't have to care about it.

5. As long as you use “set -eu” with an understanding of its shortcomings, and know how to quote variables properly, writing small and medium systems in shell is a great tradeoff between development speed and robustness. Components can be rewritten in a real systems programming language once they stabilize or require better integration than can be had by parsing the output of other commands.

jimktrains24• 10 years ago

What the heck is ip6-literal.net

So, I was looking this up as I havn't used windows in forever. I then did a `whois ipv6-literal.net` and was surprised that Microsoft doesn't own it. That seems weird for them to use it in such a way?

RGamma• 10 years ago

8. Lack of proper, well integrated, easy to use, expressive permissions system, ideally with a notion of complete isolation by default. Right now most users rely on the benevolence of software writers to not mess with their personal files, but sometimes things goes awry (that Steam homefolder deletion disaster comes to mind).

Imagine mobile OSs with just the Unix permissions system, the malware spread on those would be so humongous, it'd almost be funny again (arguably this was a long-time problem anyway privacy-wise, with software requiring privileges that couldn't be faked (e.g. giving the application a fake address book instead of your own), but at least apps couldn't easily nuke/hijack all your personal files.)

yrro11• 10 years ago

This is coming with wayland and xdg-app. I say this not to try to refute your point but to give you something to Google for if you're curious about how things will probably work in the future.

digi_owl6• 10 years ago

Android it just that, and what they do there is run each app as its own user.

pseu• 10 years ago

@7 - is that so ? I just gave up installing F# developer tools in Windows last night after two hours, 3 general install methods (check the F# foundation site) and some 6+ installer packages (some of which wanted to eat 8GB of diskspace). - And yes, my copy of windows is reasonably modern (8.1) and legal.

Contrast that with Ubuntu, where installing F# took all of 5 minutes, with one command, 200MB and I had a full IDE and F# support.

The one concession I'll make is the one you yourself seem ignorant of - ease of use pertains to your expertise with the system. If you grew up on Windows, you may get its idiosyncrasies.

RaleyField3• 10 years ago

Contrast that with Ubuntu, where installing F# took all of 5 minutes, with one command, 200MB and I had a full IDE and F# support.

Unless you want the latest version then you are cloning a few repos, compiling and hunting dependencies because building mono + ide isn't straightforward.

Houshalter3• 10 years ago

Is this an issue with Windows itself, or with developers poorly supporting Windows? I've had similar problem with installing stuff, but it's always programming related stuff. Most software just works, but try installing pip and you need to set aside the whole day for reading bad documentation that just assumes you use Linux.

MereInterest• 10 years ago

Regarding #5, I quite enjoy text-based configuration files, and can't stand systems that force me to use a GUI to change settings. If I have a text-based config file, I know that it will play nicely with git. If there are many related settings, users can change them all quickly with their preferred text editor.

gtf212• 10 years ago

+1 for GUI-based configuration being a pain, having a dotfiles repo that I can edit, clone, fork, etc. is magical (and far more flexible).

Ao7bei3s8• 10 years ago

Agreed, text based config files are good and not the problem. (Though binary formats != GUI tools only.)

I think the real problem is config files either in hard-to-parse-correctly custom ad-hoc formats or even "config files" written in a scripting language (-> impossible to parse).

All config files should use the same standard format. I'd say "like YAML", but I'm not aware of a widely-used format with standard features like file includes or data types beyond "int" and "string" (e.g. for time intervals; these really shouldn't be "just a string... with a custom format").

jefurii2• 10 years ago

Text config files plus the command line makes explainations and documentation a lot simpler, more concise, and more precise. You can exactly duplicate a series of commands and config changes. "Type this command to edit this config file, change the value of this setting to this other setting, then run this command to reload." Making documentation is often simply a matter of copying from your .bash_history.

Making documentation for graphical programs often requires screenshots and sentences like "click the third radio button on the right-hand section" that add nothing to the documentation and are easily misunderstood by hapless users. Then the developer changes the layout of the dialog box and you need a new set of screenshots. I'll grant that GUIs are more discoverable to a casual user.

I seem to recall that it's possible to automate GUI software but it seems fraught with peril in a way that automation of a commandline and text config system simply is not.

tomphoolery• 10 years ago

The emphasis on doing everything with text is not a problem, it is a major feature of Unix. Configuration management, portability, and interoperability are all a lot easier to do thanks to Unix's dedication to text as the lingua franca of the operating system

manyxcxi• 10 years ago

Totally with you. I HATE dealing with Windows server for this very reason. Whereas, even before Puppet and Chef and the like you could mostly automate the deployment and configuration of a new *nix server with shell scripts and config file templates.

Try automating the deployment of a new IIS server 8 years ago. Hell, try it today.

vacri3• 10 years ago

Windows is a lot more reliable than Linux at having things "just work" these days.

As long as you only do the things you're allowed to do. I just replaced my 6-year old Windows gaming machine, the only win machine I have. I can't even change the windowing theme - it has to be MS's preselected graphics. I wanted to turn off all the 'phone home' stuff except updates and windows defender; these are spread through half-a-dozen locations. I hadn't even got to install my first bit of software yet (firefox) and already I was limited over what can normally be done with a desktop.

"Just works" isn't really an argument when it's paired with "but you can only do these things".

Not to mention that back in the server world that lightweight virtual servers are an impossibility with Windows arena. ^nix servers are small in volume size, can run on fumes, and are largely disposable. Windows servers are (relatively) huge, slow to launch, require much more system resources, and require licensing. That isn't "just works" for me.

[text config] This is often ok, but it does make it hard to integrate with GUI tools, hence the lack of them.

Only if your GUI tools are written from the viewpoint that nothing else should touch the config file. After all, if I can write a bash script that upserts a config value in a text ini file, why can't a GUI programmer?

woodman3• 10 years ago

1. Unnecessary and confusing directory structure.

"Unnecessary" for you maybe, but have you considered the possibility that there is a reason why the directory structure is the way it is - and that the problems originally addressed may still be relevant? Here is a hint: partitions. Partitioning the files roughly by usage pattern allows you to tune performance, safety and security in a way that you would have a very hard time doing otherwise. Your suggested names make me think that you aren't very clear on the directory's actual purpose [0]. While longer names may have helped you out in understanding their purpose, once you actually learn it you're stuck with an unnecessarily long PWD that wraps each prompt.

2. Programs are mushed together and scattered...

Again, consider why it is the way it is. Do you really want to have a PATH that includes every directory for every binary on the system, or manage individual file permissions within all those directories? You want to do that with libraries as well? Just consider the complexity of what you're proposing and how you'd address: system defaults, setuid, per user preferences, dependencies, build environments... Years ago I basically did what you're suggesting, when Redhat was my daily driver. I'd build from source and install into ~/bin. Try it out for a while, you'll hate it.

4. Emphasis on text-based configuration files... hard to integrate with GUI tools...

What are you suggesting, a windows like registry? The text-based configs are no more difficult to use through a GUI than a binary representation, they're both a library function call away. Unless you are suggesting a windows like registry... but you've already pointed out how developers don't want to spend time on portability - so that can't be it.

7. General bugginess... Windows is a lot more reliable than Linux...

Ah, well try out an OS that is closer to Unix than Linux - maybe one of the BSDs. I'd put my Freebsd workstation against any flavor of Windows in a contest of uptime and performance, that is a bet I'd be happy to take. As far as Windows just working, that is true for the majority of tasks for the majority of users. But if you fall outside of that happy band of the target market, you are SOL. Consider the whole Windows telemetry issue. Also, I just noticed in my network logs that Windows update is sending out IPv6 dns requests despite the fact that I've disabled it on the network interface and tweaked several registry variables... there is nothing I can do about it. It would be a pretty simple fix for any opensource OS though.

[0] https://www.freebsd.org/doc/handbook/dirstructure.html

marcosdumay2• 10 years ago

Do you really want to have a PATH that includes every directory for every binary on the system, or manage individual file permissions within all those directories?

No way. But I'd love to gt ride of the plain PATH, replacing it with a hierarchical PATH with a convention. Maybe with every 'bin' directory inside that path getting in the search path, or maybe something that let me nest things deeper.

One can not do this in Unix, and that's the point.

Jedd• 10 years ago

  > How about defending these?
  > 1. Unnecessary and confusing directory structure. `/etc`? Why not `/config`? 
  > `/usr` instead of `/system`, `/var` instead of ... well who knows. The maximum
  >   directory name length is no longer 3 characters.

I know yrro already explained the ludicrously inconsistent nature of the OS you're apparently defending, but I'll add in:

Why do I need to edit c:\Windows\System32\Drivers\etc\hosts (in what way is hosts related to bit-length or a driver?)

Why .htm rather than .html?

Why programiwanttorun.exe rather than programiwanttorun

/system is as overloaded a word as any in IT. /config doesn't accurately reflect what /etc is about (but in any case, the latter is not a great barrier to entry)

If you're complaining about limits on directory entries .. you're skating around on very thin ice if you're on the NTFS lake (compared to any of xfs, btrfs, reiserfs, ext2/3/4fs, etc)

  > 2. Programs are mushed together and scattered through the filesystem rather
  > than stored in separate locations. This basically means applications are
  > install-only. Yeah, package managers try to keep track of everything, but
  > that is just hacking around the problem, and most developers don't want to
  > spend hours creating 5 different distro packages.

14,000 registry entries for one suite of software ... how is that not 'mushed together and scattered'.

Applications are not install-only. Because package managers (or, rather, distributions) managed to solve this problem elegantly more than a decade ago, I don't know how you can credibly make this claim.

Is 'mushed together and scattered' a contradiction?

Building packages for a variety of distros is a solved problem (again, it has been for a decade or more).

  > 3. Not strictly Unix, but the mess of glibc with respect to ABI compatibility,
  >  static linking, etc. is ridiculous. Musl fixes most of this fortunately.

It's hard to not sarcastically comment with the observation that the phrase DLL Hell did not originate within the nix world.

More pragmatically, I rarely (in twenty years) have had glibc issues. I think perhaps 3 times. All easily solved.

  > 4. Emphasis on text-based configuration files. This is often ok, but it does
  >  make it hard to integrate with GUI tools, hence the lack of them.

The biggest complain with Win95 was the move away from .ini files (text-based).

GUI tools do not intrinsically have an issue dealing with text-based configuration files.

I posit the problem you're describing is the fact that text-based configuration files often contain useful human-readable components (which non-text-file config systems, such as 'the registry' lack) which is slightly harder to maintain using automated tools. But only slightly. As noted elsewhere, these are typically only a library call away.

  > 5. Emphasis on shell scripts. Fortunately this is starting to change, but
  > doing everything with shell scripts is terribly bug-prone and fragile.

Doing anything badly is fragile. Shell scripts aren't intrinsically bad - as evinced by the success of shell scripts.

I don't know many people who have significant experience with apt|rpm && sccm (for example) ... but I know a couple, and the fragility of shell scripts leads to fewer expletives than the alternative.

  >  6. X11. 'nuff said about that. When is Wayland going to be ready again?

Are you suggesting that a system that completely disavows any network-awareness is preferable to one, designed >20 years ago, that does it fairly well?

What problems have you had with X11 that aren't dwarfed by citrix / rdp / single-user consoles / etc?

  > 7. General bugginess. I know stuff works 90% of the time, but that 10% is
  > infuriating. Windows is a lot more reliable than Linux at having things
  > "just work" these days.

Sounds like hyperbole. If things in the GNU/Linux world broke 10% of the time there'd be a lot fewer people using it - and if Microsoft Windows was more reliable than GNU/Linux, there'd be a lot more people moving towards it rather than away from it.

bitwize2• 10 years ago

X11 is inherently insecure. With Wayland, the compositor itself is privileged but all clients get access to only their frame buffers and event streams.

Network transparency is mostly irrelevant on modern desktop systems, X11 remotes modern apps poorly at best, and if you really need remote desktop access you know where to find RDP and SPICE.

The Wayland switch will be a win because X11 is almost pure cruft. The good parts are what was kept in Wayland.

AndyMcConachie2• 10 years ago

Linux != UNIX

jsz0• 10 years ago

`/etc`? Why not `/config`?

/etc contains more than just config files so /config would be a misleading (or at least overly specific) name. If we went that route we'd need dozens of top level directories to cover everything. I do prefer OSX's more user friendly directory layout but the traditional directory structure has been around for decades. It works fine.

Retra• 10 years ago

/etc contains more than just config files because it's called '/etc' and not '/config'.

Any why would you need dozens of top level directories? I can't imagine that you could name even one dozen completely orthogonal aspects of program and system configuration that can't be put into a _some_ meaningful hierarchy.

dominotw2• 10 years ago

Programs are mushed together and scattered through the filesystem rather than stored in separate locations. This basically means applications are install-only. Yeah, package managers try to keep track of everything, but that is just hacking around the problem, and most developers don't want to spend hours creating 5 different distro packages.

What about things like encap/gnu stow which symlink files from one single package dir.

skocznymroczny2• 10 years ago

As for 1. and 2., I kind of like how Apple solved it. When moving Xcode from one Mac machine to the other, I only needed to copy /Applications/Xcode.app directory to the other machine and everything magically worked, configuration files are kept to their applications rather than littering the filesystem.

mystikal2• 10 years ago

OS X is actually certified as a Unix, unlike many Linux distros.

cyphar7• 10 years ago

Do you mean POSIX? In which case you should be aware that it actually costs money to get licensed as a POSIX-certified OS. If you actually meant UNIX, then of course GNU (GNU is not UNIX) isn't UNIX. It's in the name. At best the Linux kernel is a cousin of UNIX.

joosters• 10 years ago

I can never remember find's strange command line arguments, so I end up writing the easy replacement:

  find . |grep \\.txt

The backslashes are not very intuitive, but if you miss them out entirely, you'll still likely get good enough results.

BozeWolf• 10 years ago

Haha! Yes! +1 for this. I do exactly the same thing. Or even just grep txt. The find command just is sometthing i cant get into my muscle memory (despite using linux for more the 15 years)

rat873• 10 years ago

for files on disk (not external disk) older then a day you can run

`locate` or `locate --regex`

Its faster since it uses a path database(If you have root you can run sudo updatedb to update it beforehand)

someoneretarded• 10 years ago

"Since we only use apt-get for installing stuff, why not?

apt-get something instead of apt-get install something"

wat? How dumb do people get?

nunobrito6• 10 years ago

If you read the blog carefully, you notice that the topic is about usability for upcoming command line tools.

An hypothetical apt something follows the pattern found on curl, ping, unzip, ... Correcting user input when badly typed is something git already serves as example. So, labeling as dumb one of the parties at a discussion about intuitive command line switches as if they are immutable should be done with more substance.

btw, when reading your reply this was the first thing coming to my mind: http://dilbert.com/strip/2007-11-16

Have fun. :-)

gtf212• 10 years ago

People are still having windoze vs. unix fights? In this day and age?

AsyncAwait3• 10 years ago

@7 I see this point repeated often without further clarification, what exactly is more buggy?

I can tell you from personal experience that with a reasonably modern Linux distro, my laptop works out of the box without any problems and I've not experienced any significant system-level bugs in a long time.

Meanwhile in Windows, my sound doesn't work at all when I wake up the laptop from sleep, Windows update tries to override the GPU driver with an older version from Windows update and every time I have > 10 Chrome tabs open, the whole system locks up regularly. Not to mention that the Windows registry is still a complete mess and trying to COMPLETELY remove a piece of software is an impossible task.

I am not saying Linux is perfect and yes, Windows works better in the games department, but I am not sure I'll call Windows less buggy.

FDominicus• 10 years ago

1) could be a running gag. If you know it you know it, if you don't why not learn it? 2) mushed together /bin, /sbin/, /usr/bin, /usr/sbin/ usr local Well yes that may be hard to get if you exectubables are scatterd around as in windows in every other directoy. what a "big" difference 3) Yes DLl-Hell never ever has happened to Windows users - never 4) Oh yes it's better to have on registry and nobody knows which is for what. And if the registry is broken the whole system does not even run any more - yes that sounds as if that would be much better.. And no there is no graphical frontend for whatever in webmin. 5) Shell script are programs, and you can use them for scripting. what problem do you have with that? 6) So AFAIKT it runs here without troubles and update/upgrades are just an apt-get upgrade away. 7) Teh IT backbones are servers and most servers run under Linux. That should give you a hint.

You arguments are none. They are just your opinion which is not backed by any knowledge. So welcome in the land of good-doers.

Reliability is a word that Windows users have just learned the last few Windows incarnations. Long running servers are usual with Unices that's hardly the case for any Windows.

And for Windows nearly all malware works. But hey who needs reliability if it's all that nice and colourful

AndyMcConachie2• 10 years ago

The equivalent of "dir *.txt /s" in UNIX is "ls -R|grep txt$".

nunobrito6• 10 years ago

I find that syntax "good enough" for my own usage. YMMV when considering it outputting not just files with txt as extension, but also somewhere on its name.

Someone else mentioned a workaround by adding the escaped dot in order to be fully equivalent to the dir syntax.

skocznymroczny2• 10 years ago

Is Bash really better at wildcard expansion than cmd? I mean, sometimes you don't want to do wildcard expansion in the shell. copy .txt .bak would be much harder to write in Bash I suppose.

dllthomas• 10 years ago

For the record, I would probably write this:

    for i in *.txt; do
        cp "$i" "${i%txt}.bak"
    done

OJFord4• 10 years ago

    > This is not available in the version of bash that comes
    > with OS X

Almost nobody that doesn't comment "what's Terminal?" on an article/etc. should be using "the version of bash that comes with OS X".

In defense of Unix

Related Stories