Switch to .ruby extension?

ruby-talk
1

The current convention for Ruby source file names is to end them with
a .rb extension. This strikes me as too minimalistic. Why not .ruby?

File extensions of more than three characters are very commonplace,
now that Windows supports them. HTML files generally have a .html
extension; you very rarely see .htm anymore. And Java source and
object files have .java and .class extensions, respectively. "ruby" is
only two more letters than "rb", but I think it's clearer and more
aesthetically pleasing.

So, I propose a change in the convention from .rb to .ruby. Now, I'm
not suggesting that everyone change all of their existing scripts and
libraries, or even the files in the Ruby distribution. That would be
excessive for such a small thing. But, for example, the Windows
installer could associate both .rb and .ruby files with ruby.exe, and
we could start using .ruby in new projects.

Yes it's a silly little thing. But ever since Y2K, I've been wary of
excessive abbreviation. :slight_smile: Besides, it's the attention to the little
things that makes Ruby so appealing.

2

Karl von Laudermann wrote:

... we could start using .ruby in new projects.

What stops you from doing so now?

You're sure never going to get me to start mangling my script names that
way. I leave script names unadorned, in case I ever wish to change the
implementation. This already paid off with shell scripts that I moved to
ruby. :slight_smile:

···

--
Neil Stevens - neil @hakubi.us
"The world is a dangerous place to live; not because of the people who
are evil, but because of the people who don't do anything about it."
                                                 -- Albert Einstein(?)

3

The obsessive levels of abbreviation in the *nix world infuriate me. Especially when it's so easy to make verbose and abbreviated commands exist together, and do the same thing.

I remember when I first started using linux (now I use FreeBSD, which is no better in this regard), I spent an hour trying to figure out how to copy a file..."copy" didn't work. Searching the internet for info on "copying" didn't turn up anything, probably because Google wasn't what it is now, back then. I had to finally get on IRC and ask someone how to copy - Turns out it's "cp". It will take me a decade of typing "cp", with it's two fewer letters than "copy", to earn back the hour it took me to figure out the command in the first place.

When I mention to *nix people how easy it would be to make "copy" work simultaneously along with "cp" for the sake of user-friendliness, I'm met with scorn and rage, and cat-calls saying "go back to windows". It seems that most *nix people have no interest in other people, even to the small extent of making things accessible for newcomers to their favorite tools. That's what I call an antisocial failure to communicate.

Ruby ought to have a either a .ruby extension, or no extension at all, as someone else mentioned in this thread. I'm sure lots of anti-social types find their meaning in life by insulting the intelligence of people who can't figure out what ".rb" means, but I'm not one of them. I wholeheartedly agree with you, that abbreviations are ancient relics of an elitist and anti-social past, and they should be buried with the creaky old coots that invented them.

Karl von Laudermann wrote:

···

The current convention for Ruby source file names is to end them with
a .rb extension. This strikes me as too minimalistic. Why not .ruby?

File extensions of more than three characters are very commonplace,
now that Windows supports them. HTML files generally have a .html
extension; you very rarely see .htm anymore. And Java source and
object files have .java and .class extensions, respectively. "ruby" is
only two more letters than "rb", but I think it's clearer and more
aesthetically pleasing.

So, I propose a change in the convention from .rb to .ruby. Now, I'm
not suggesting that everyone change all of their existing scripts and
libraries, or even the files in the Ruby distribution. That would be
excessive for such a small thing. But, for example, the Windows
installer could associate both .rb and .ruby files with ruby.exe, and
we could start using .ruby in new projects.

Yes it's a silly little thing. But ever since Y2K, I've been wary of
excessive abbreviation. :slight_smile: Besides, it's the attention to the little
things that makes Ruby so appealing.

4

Karl von Laudermann wrote:

The current convention for Ruby source file names is to end them with
a .rb extension. This strikes me as too minimalistic. Why not .ruby?

File extensions of more than three characters are very commonplace,
now that Windows supports them. HTML files generally have a .html
extension; you very rarely see .htm anymore. And Java source and
object files have .java and .class extensions, respectively. "ruby" is
only two more letters than "rb", but I think it's clearer and more
aesthetically pleasing.

So, I propose a change in the convention from .rb to .ruby. Now, I'm
not suggesting that everyone change all of their existing scripts and
libraries, or even the files in the Ruby distribution. That would be
excessive for such a small thing. But, for example, the Windows
installer could associate both .rb and .ruby files with ruby.exe, and
we could start using .ruby in new projects.

The package installer for Blogtari uses the .ruby extension.

This came out of necessity; I moved from distributing the app as a tarball to deploying a self-extracting Ruby script that prompts the user for configuration details, writes out (or updates) the config file, and installs the program. But whereas serving up *.tgz worked fine, serving up *.rb from the web server caused it to execute on the server :).

While there are any number of workarounds for this, I opted to use the .ruby extension and tell Apache to serve it as a particular MIME type so that browsers would prompt the user to save it to disk.

Jamess

5

Karl von Laudermann wrote:

Yes it's a silly little thing. But ever since Y2K, I've been wary of
excessive abbreviation. :slight_smile: Besides, it's the attention to the little
things that makes Ruby so appealing.

What things would explode if *.rb is not changed to *.ruby in 2038 or 3000? :slight_smile:

I think we'll see .py -> .python first before we ever see .rb -> .ruby.

I vote -1.

···

--
dave

6

Karl von Laudermann wrote:

The current convention for Ruby source file names is to end them with
a .rb extension. This strikes me as too minimalistic. Why not .ruby?

What is your suggestion for .rbw (on Windows)? .rubyw? (Probably not, since you _hate_ abbreviation :-). .rubywin? .rubywindows?

Also there might be .rbc (for compiled bytecode) or .rb2 in the future. I'd hate to have too many letters as extension names.

I think there is also .rbx and a few others being used.

IMO, having a short "rb" prefix for all these is better than "ruby".

···

--
dave

7

Karl von Laudermann wrote:

... we could start using .ruby in new projects.

What stops you from doing so now?

Well, it's not just a convention. it's built-in. Try requiring 'foo' when the file is named foo.rb.

FWIW, I see no reason not to support this, as long as it's an alternate extension. Having a file named foo.ruby is at least as easy to recognize as foo.rb.

You're sure never going to get me to start mangling my script names that
way. I leave script names unadorned, in case I ever wish to change the
implementation. This already paid off with shell scripts that I moved to
ruby. :slight_smile:

Same here :slight_smile: But I think OP was talking about libraries/included code.

--
Neil Stevens - neil @hakubi.us
"The world is a dangerous place to live; not because of the people who
are evil, but because of the people who don't do anything about it."
                                                 -- Albert Einstein(?)

"I should have been a plumber." -- Albert Einstein :slight_smile:

···

On Jun 11, 2004, at 10:23 AM, Neil Stevens wrote:

8

Hello Neil,

Karl von Laudermann wrote:

... we could start using .ruby in new projects.

What stops you from doing so now?

Some braindead lines in the ruby interpreter. You can't even "require" rbw files
without patching the hardcoded extensions names in eval.c

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

9

Tyler Zesiger wrote:

The obsessive levels of abbreviation in the *nix world infuriate me. Especially when it's so easy to make verbose and abbreviated commands exist together, and do the same thing.

I remember when I first started using linux (now I use FreeBSD, which is no better in this regard), I spent an hour trying to figure out how to copy a file..."copy" didn't work. Searching the internet for info on "copying" didn't turn up anything, probably because Google wasn't what it is now, back then. I had to finally get on IRC and ask someone how to copy - Turns out it's "cp". It will take me a decade of typing "cp", with it's two fewer letters than "copy", to earn back the hour it took me to figure out the command in the first place.

True. But the best thing would have been to read a tutorial of some
kind. It would have taken an hour, and you might have saved many hours
that you now will not get back.

When I mention to *nix people how easy it would be to make "copy" work simultaneously along with "cp" for the sake of user-friendliness, I'm met with scorn and rage, and cat-calls saying "go back to windows". It seems that most *nix people have no interest in other people, even to the small extent of making things accessible for newcomers to their favorite tools. That's what I call an antisocial failure to communicate.

Heh heh, no scorn and rage here.

Ordinarily this would be easy in Unix -- you'd make a link from cp to
copy. But it doesn't work here (unless I'm behind the times) for an
interesting reason. Such programs as cp. mv, and ln are traditionally
actually links to the *same* program on disk. Their different behavior
is explained by the fact that this program checks argv to see what name
it was invoked with, in order to know how to behave.

Believe me, this made a lot more sense in 1972 than it does today.

Of course, most shells have an "alias" feature; you can do something
like alias copy=cp or the like.

Failing that, you could always make your own script "copy" that simply
said cp $* or whatever.

Ruby ought to have a either a .ruby extension, or no extension at all, as someone else mentioned in this thread. I'm sure lots of anti-social types find their meaning in life by insulting the intelligence of people who can't figure out what ".rb" means, but I'm not one of them. I wholeheartedly agree with you, that abbreviations are ancient relics of an elitist and anti-social past, and they should be buried with the creaky old coots that invented them.

LOL!

There are many things in society, not just in computing, where this is
true. :slight_smile:

Hal Fulton,
Creaky Old Coot

10

Tyler Zesiger wrote:

The obsessive levels of abbreviation in the *nix world infuriate me. Especially when it's so easy to make verbose and abbreviated commands exist together, and do the same thing.

I remember when I first started using linux (now I use FreeBSD, which is no better in this regard), I spent an hour trying to figure out how to copy a file..."copy" didn't work. Searching the internet for info on "copying" didn't turn up anything, probably because Google wasn't what it is now, back then. I had to finally get on IRC and ask someone how to copy - Turns out it's "cp". It will take me a decade of typing "cp", with it's two fewer letters than "copy", to earn back the hour it took me to figure out the command in the first place.

When I mention to *nix people how easy it would be to make "copy" work simultaneously along with "cp" for the sake of user-friendliness, I'm met with scorn and rage, and cat-calls saying "go back to windows". It

Go back to windows :wink:

More seriously, In Unix you spend almost all your time at the command prompt, so it would "infuriate" me if I had to type at least twice as much all the day if commands were called as you suggest. As for newcomers, short command names is the least problem they would encounter if they switch from Windows (for completely fresh people it does not matter what command set to learn anyway).

On the other hand, you have a lot of means to alias any command in any Unix shell.

···

seems that most *nix people have no interest in other people, even to the small extent of making things accessible for newcomers to their favorite tools. That's what I call an antisocial failure to communicate.

Ruby ought to have a either a .ruby extension, or no extension at all, as someone else mentioned in this thread. I'm sure lots of anti-social types find their meaning in life by insulting the intelligence of people who can't figure out what ".rb" means, but I'm not one of them. I wholeheartedly agree with you, that abbreviations are ancient relics of an elitist and anti-social past, and they should be buried with the creaky old coots that invented them.

Karl von Laudermann wrote:

The current convention for Ruby source file names is to end them with
a .rb extension. This strikes me as too minimalistic. Why not .ruby?

File extensions of more than three characters are very commonplace,
now that Windows supports them. HTML files generally have a .html
extension; you very rarely see .htm anymore. And Java source and
object files have .java and .class extensions, respectively. "ruby" is
only two more letters than "rb", but I think it's clearer and more
aesthetically pleasing.

So, I propose a change in the convention from .rb to .ruby. Now, I'm
not suggesting that everyone change all of their existing scripts and
libraries, or even the files in the Ruby distribution. That would be
excessive for such a small thing. But, for example, the Windows
installer could associate both .rb and .ruby files with ruby.exe, and
we could start using .ruby in new projects.

Yes it's a silly little thing. But ever since Y2K, I've been wary of
excessive abbreviation. :slight_smile: Besides, it's the attention to the little
things that makes Ruby so appealing.

11

heh :slight_smile: I had a similar experience, coming from a Mac, with no command line, to a Mac running OS X, with a full fledged UNIX interface, when you want it... it was all very frustrating until a friend pointed me in the direction of the 'apropos' tool. After that, it was mostly smooth sailing.

I don't think that there should be extra commands littering up the one monolithic namespace of shell commands. A simple 'help' tool, which relays a few ways of finding various commands, should, IMHO, be included. A few tips about apropos, man, and a short note about how command line arguments work. That would be enough, I think, to get a determined person up and running.

cheers,
Mark

···

On Jun 11, 2004, at 10:55 AM, Tyler Zesiger wrote:

I remember when I first started using linux (now I use FreeBSD, which is no better in this regard), I spent an hour trying to figure out how to copy a file..."copy" didn't work. Searching the internet for info on "copying" didn't turn up anything, probably because Google wasn't what it is now, back then. I had to finally get on IRC and ask someone how to copy - Turns out it's "cp". It will take me a decade of typing "cp", with it's two fewer letters than "copy", to earn back the hour it took me to figure out the command in the first place.

12

Tyler Zesiger wrote:

The obsessive levels of abbreviation in the *nix world infuriate me. Especially when it's so easy to make verbose and abbreviated commands exist together, and do the same thing.

Of course you understand things like 'ls', 'pwd', 'cd', '/usr/bin', and many other things in Unix are historical? They *did* need to abbreviate things as memory was very very tiny back then.

I don't think Unix/Linux developers suffers from obsessive levels of abbreviation right now. For example: Gnome programs are named very verbosely: gnome-config, gnome-terminal, etc. Also see how Redhat, Mandrake, Apple (OS X), etc. name their programs.

Of course, the filesystem layout will probably stay more or less the same (or at least evolve very very slowly) because it's just too hard to change paths and dirs in everything. There are efforts though, like Gobolinux.

But I do find that many Perl programmers' tendency to abbreviate everything is a little bit too much. $prog or $prg instead of $program, $chg instead of $change, $txt instead of $text (please, it's just one letter!), etc. This does infuriate me sometimes.

···

--
dave

13

Neil Stevens <neil @ hakubi.us> wrote in message news:<3Rlyc.22289$TR1.4566@nwrddc01.gnilink.net>...

Karl von Laudermann wrote:

> ... we could start using .ruby in new projects.

What stops you from doing so now?

Well, at home I have a Mac, so I will probably use .ruby from now on,
since I can just start each file with the line "#!/usr/local/bin/ruby"
to tell it how to run. However, I'll have to specify the full filename
when I use the require or load methods. But at work, where I use
Windows, I'd have to manually map the .ruby extension to ruby.exe on
every machine that the scripts have to run on. I will have to remember
to do this each time a new machine needs to run my Ruby scripts, when
I first install Ruby on it. So I'll probably stick to .rb at work.

I'm just proposing the following:

1) Ruby should be modified so that you don't have to specify the file
extension when using require or load, if the file ends with .ruby,
just like is already true with files that end with .rb.

2) The Windows installer should associate .ruby with ruby.exe, just
like it already does with .rb

AFAIK, these are the only two things that would need to be done to
make .ruby as "supported" an extension as .rb is now.

But ideally, I'd also like to see a switch to .ruby as being the norm
in the Ruby community. That means that, for example, if a newbie is
reading a Ruby tutorial, the tutorial might say "Ruby scripts are
typically stored in files ending with .ruby", whereas right now such
existing tutorials would say .rb instead. Also, if said newbie is
downloading sample Ruby programs, he would see that the files
typically end in .ruby.

To the person who said that users will never see installed library
files, I must respectfully disagree. I know that I've poked through
the Ruby lib directory out of curiosity to see what's there. And when
I download a new library, I generally poke through the installer
directories before running the install. Heck, usually the library has
an install script called setup.rb at the top level of the installer
directory, so there's no way to avoid seeing that. So my point is, I
do often see files ending in .rb that I didn't write. The impression I
can't avoid getting is that .rb is the standard extension, and that
it's what I therefore should use myself.

To sum up, what I'm saying is, I'd like to see .ruby become supported
as a standard extension, just like .rb already is, by doing the 2
things mentioned above. In addition, I'd *ideally* like everyone to
agree with me and start treating .ruby as the standard extension, so
that newbies will get the impression that it's the standard extension
when they see everyone else's Ruby files. But I realize that different
people have different tastes, so I'm not holding my breath on the
latter. :slight_smile: Simply having both extensions be supported is fine.

Now if you'll excuse me, I'm going to go to the Perl newsgroup and
propose that they change the standard extension from .pl to something
more Perl-like, such as .$`_
:slight_smile:

14

I remember when I first started using linux (now I use FreeBSD, which
is no better in this regard), I spent an hour trying to figure out

how

to copy a file..."copy" didn't work. Searching the internet for info

on

"copying" didn't turn up anything, probably because Google wasn't
what it is now, back then. I had to finally get on IRC and ask

someone how

to copy - Turns out it's "cp". It will take me a decade of typing

"cp",

with it's two fewer letters than "copy", to earn back the hour it
took me to figure out the command in the first place.

I know exactly what you mean, because "dir" and "del" in DOS are *so*
intuitive. In fact, "copy" is also elitist; "duplicate" is even more
user friendly.

All sarcasm aside, I don't think anything short of a decent AI
interpreter will make the command line "user friendly". There's a
threshold before which trying to make things more user friendly is
counter productive -- you don't really save most people any time
learning the system (except in a few edge cases), and you make things
more painful on a day-to-day basis for people who already know the
system. Beyond that threshold, of course, a system *can* be user
friendly enough to make the extra typing worthwhile. I'd *love* to be
able to tell my system, in plain English (or German, or French, or
Esperanto) "Open the most recent version of my resume in openoffice".
Anything less than that is just optimizing the syntax for a select
group, and Linux (and Unix) chooses that group to be people who use the
shell enough to appreciate the fewer keystrokes.

If you don't agree with me, odds are *really* good that you've never
played Zork. I'm not the first to argue that that trying to make
things more natural is worse than not trying at all if you can't meet
that threshold.

--- SER

15

Mark Hubbart wrote:

Karl von Laudermann wrote:

... we could start using .ruby in new projects.

What stops you from doing so now?

Well, it's not just a convention. it's built-in. Try requiring 'foo'
when the file is named foo.rb.

FWIW, I see no reason not to support this, as long as it's an alternate
extension. Having a file named foo.ruby is at least as easy to
recognize as foo.rb.

Sure, I'm concerned about scripts, not libraries, though.

You're sure never going to get me to start mangling my script names
that
way. I leave script names unadorned, in case I ever wish to change the
implementation. This already paid off with shell scripts that I moved
to
ruby. :slight_smile:

Same here :slight_smile: But I think OP was talking about libraries/included code.

Well, he did say scripts and libraries. I don't see what the names matter
for libraries, though. Only the scripts are user-visible.

···

On Jun 11, 2004, at 10:23 AM, Neil Stevens wrote:

--
Neil Stevens - neil @hakubi.us
"The world is a dangerous place to live; not because of the people who
are evil, but because of the people who don't do anything about it."
                                                 -- Albert Einstein(?)

16

I think I may be earning myself a reputation as a user-friendliness Nazi, but I see no reason why a CLI can't be *very* user friendly. For example, if someone types in "copy", it could spit out some context-sensitive help about the right way to do a copy. These are the nice little touches that take a product into the realm of maturity, in my opinion. When it's so well designed, and so well understood by the designers, that it's designed to help you get to where you're trying to go, even when you're not exactly sure how to proceed.

Most people argue that, if you've got the gumption to use Unix, you've got the gumption to hike the learning curve - And if you need to have your hand held along the way, you're better off with a GUI'd OS anyways. All of that may be true, but it's beside the point. The point is that the paradigm is all wrong. To intentionally make things cryptic, and then to leave them that way for decades on end is deplorable, and speaks volumes about the direction that The Powers That Be are headed in.

Is it a crime to make a powerful and sophisticated software system easy enough for children to use? Is it so bad if all the complexity is tucked away under a nice interface until needed? (Be it command line or GUI, or who knows what else). MacOSX seems to be a hit with Mac users. Apparently, shoving all the sophistication under the rug has worked for them. *nix OS's are a decade behind in the UI/user-friendliness department, and there's no good reason for it to be like that. The hardcore hackers don't need to lose anything if Timmy The Five Year Old has an overlying interface to Unix that makes sense to him, so why the incredible opposition to user-friendliness?

My beef is with *nix people who think user-friendliness is a bad thing - A threat to their way of thinking. It's utter nonsense. Software is kind of a commodity these days, in that oftentimes, you can't even give it away. That which isn't used, has no value. That which is used more, has more value.

The user-friendliness paradigm in the *nix world should change, it makes no difference whether it necessarily needs to or not. Everything good, should be easy to use, otherwise, it might as well not be so good. If someone out there isn't able to use it, for that person, it doesn't even exist.

That's the way I think.

Mark Hubbart wrote:

···

On Jun 11, 2004, at 10:55 AM, Tyler Zesiger wrote:

I remember when I first started using linux (now I use FreeBSD, which is no better in this regard), I spent an hour trying to figure out how to copy a file..."copy" didn't work. Searching the internet for info on "copying" didn't turn up anything, probably because Google wasn't what it is now, back then. I had to finally get on IRC and ask someone how to copy - Turns out it's "cp". It will take me a decade of typing "cp", with it's two fewer letters than "copy", to earn back the hour it took me to figure out the command in the first place.

heh :slight_smile: I had a similar experience, coming from a Mac, with no command line, to a Mac running OS X, with a full fledged UNIX interface, when you want it... it was all very frustrating until a friend pointed me in the direction of the 'apropos' tool. After that, it was mostly smooth sailing.

I don't think that there should be extra commands littering up the one monolithic namespace of shell commands. A simple 'help' tool, which relays a few ways of finding various commands, should, IMHO, be included. A few tips about apropos, man, and a short note about how command line arguments work. That would be enough, I think, to get a determined person up and running.

cheers,
Mark

17

Lothar Scholz wrote:

Hello Neil,

> Karl von Laudermann wrote:

... we could start using .ruby in new projects.

> What stops you from doing so now?

Some braindead lines in the ruby interpreter. You can't even "require" rbw files
without patching the hardcoded extensions names in eval.c

It's not braindead. It's _as designed_ :slight_smile: The same for perl and python (which will automatically add .pm or .py/.pyc/.pyo).

Do you expect ruby to check every possible extension?

···

--
dave

18

David Garamond wrote:

Tyler Zesiger wrote:

The obsessive levels of abbreviation in the *nix world infuriate me. Especially when it's so easy to make verbose and abbreviated commands exist together, and do the same thing.

...

But I do find that many Perl programmers' tendency to abbreviate everything is a little bit too much. $prog or $prg instead of $program, $chg instead of $change, $txt instead of $text (please, it's just one letter!), etc. This does infuriate me sometimes.

The May issue of The Believer [0], a literary mag published in the USA, has an article by David Ng ostensibly about the literature of software development.

He discusses what he sees as geek pride and bravado in using languages that lend themselves toward complex and/or terse code. In his view, hardcore geeks disparage Visual Basic in favor of Java because VB is too easy to learn and read; perl gets extra high points for executable line noise and the barrier to comprehension (at least for outsiders). He's somewhat right, at least to the extent that there exists a juvenile coder subculture that values obfuscation. (I suspect that these are the same people who write 'windoze', or knock the use of variable names longer that 3 characters.)

Ng misses the real point, which is that the better hackers prefer languages that enable expressiveness. Often, the easy-to-learn, easy-to-use language is also "dumbed down" in some way to impede any real code eloquence. But hackers aren't looking for complexity for its own sake (though it may come as a side effect).

It's the job market and management that pushes them toward Java; it's the thought-to-code ratio that draws them to Lisp, Ruby, and so on.

James

[0] http://www.believermag.com/

19

Karl von Laudermann wrote:

Neil Stevens <neil @ hakubi.us> wrote in message
news:<3Rlyc.22289$TR1.4566@nwrddc01.gnilink.net>...

Karl von Laudermann wrote:

> ... we could start using .ruby in new projects.

What stops you from doing so now?

Well, at home I have a Mac, so I will probably use .ruby from now on,
since I can just start each file with the line "#!/usr/local/bin/ruby"
to tell it how to run. However, I'll have to specify the full filename
when I use the require or load methods. But at work, where I use
Windows, I'd have to manually map the .ruby extension to ruby.exe on
every machine that the scripts have to run on. I will have to remember
to do this each time a new machine needs to run my Ruby scripts, when
I first install Ruby on it. So I'll probably stick to .rb at work.

I don't understand why it matters what the file names are for libraries.
What are you going to do if/when ruby starts getting some preprocessing
like Python gets? If you're hard-coding the full file names that'll break
your scripts, won't it?

The only user-visible file names are the script names, so those seem to be
the only ones that should matter.

Yes, make sure to do /usr/bin/env ruby, not /usr/local/bin/ruby. The former
will work work for more people (like those who have to put ruby in
$(HOME)/bin).

···

--
Neil Stevens - neil @hakubi.us
"The world is a dangerous place to live; not because of the people who
are evil, but because of the people who don't do anything about it."
                                                 -- Albert Einstein(?)

20

I don't know how much of the thread you read through, but I repeated at least half a dozen times that the command line isn't the issue. It's the general anti-userfriendliness mentality in the *nix community. I just started with "cp" as an example.

SER wrote:

···

I remember when I first started using linux (now I use FreeBSD, which
is no better in this regard), I spent an hour trying to figure out

how

to copy a file..."copy" didn't work. Searching the internet for info

on

"copying" didn't turn up anything, probably because Google wasn't
what it is now, back then. I had to finally get on IRC and ask

someone how

to copy - Turns out it's "cp". It will take me a decade of typing

"cp",

with it's two fewer letters than "copy", to earn back the hour it
took me to figure out the command in the first place.

I know exactly what you mean, because "dir" and "del" in DOS are *so*
intuitive. In fact, "copy" is also elitist; "duplicate" is even more
user friendly.

All sarcasm aside, I don't think anything short of a decent AI
interpreter will make the command line "user friendly". There's a
threshold before which trying to make things more user friendly is
counter productive -- you don't really save most people any time
learning the system (except in a few edge cases), and you make things
more painful on a day-to-day basis for people who already know the
system. Beyond that threshold, of course, a system *can* be user
friendly enough to make the extra typing worthwhile. I'd *love* to be
able to tell my system, in plain English (or German, or French, or
Esperanto) "Open the most recent version of my resume in openoffice".
Anything less than that is just optimizing the syntax for a select
group, and Linux (and Unix) chooses that group to be people who use the
shell enough to appreciate the fewer keystrokes.

If you don't agree with me, odds are *really* good that you've never
played Zork. I'm not the first to argue that that trying to make
things more natural is worse than not trying at all if you can't meet
that threshold.

--- SER