I tried renaming a file in Ubuntu

blakeyrat

Mostly good points, but a lot of this has nothing to do with the OS. Confusingly-named utilities (not part of the OS), badly designed GUIs, unresponsive and uncommunicative programs – crappy software is crappy software, no matter what OS it runs on, and it's not the OS's fault.

I think you mean it's not the kernel's fault (cue standard rant about how Linux users can't decide what to call their stuff and how it changes constantly). The stuff we're talking about ships with the OS, so it's most certainly the OS's fault.

Cassidy

@boomzilla said:

A better question would be how he defines "useful world" and "inherently discoverable".

I was hoping the answer to my question would have featured those definitions.

e4tmyl33t

@Cassidy said:

@boomzilla said:
A better question would be how he defines "useful world" and "inherently discoverable".

I was hoping the answer to my question would have featured those definitions.

Ok, fine, in short-speak:

"Useful world": A world in which technology is useful, easy to use, and generally makes life a better place.
"Inherently discoverable": Able to be picked up and used for common everyday tasks by anyone without needing to consult a manual, geeky friend, or forum thread to figure out how to do said common tasks.

spamcourt

@blakeyrat said:

Ok, you've spent years learning Bash. How long have you spent learning VBScript or JScript or AppleScript?
Your argument doesn't boil down to "the CLI is better", it boils down to "I know the CLI better". That's different.

JScript or VBScript (not sure about AppleScript) would probably be much more cumbersome to type in an interactive shell. Besides, it's still a textual interface. Unix CLI wins over these just because it's more terse. And ironically, more discoverable. Where do I look up, I don't know, what objects are available through CreateObject and how can I use them? In bash I can try "help", "man", or in the worst case running the command with "--help" or "-h". Without even switching to a separate window with a help viewer or a browser. Most of the time some help will be there.

Not that it's perfect. Being based upon manipulating text makes the Unix shell terribly inefficient and prone to bad coding. There are many gotchas which may bite you in the ass when your script is sloppy — and most of the time it is sloppy. Some of the programs' output is not machine-readable. So parsing it amounts to scrapping, and it's common, even though it often breaks in different locales.

I would gladly see the traditional textual shell replaced with something similar to TermKit.

e4tmyl33t

@spamcourt said:

JScript or VBScript (not sure about AppleScript) would probably be much more cumbersome to type in an interactive shell. Besides, it's still a textual interface. Unix CLI wins over these just because it's more terse. And ironically, more discoverable. Where do I look up, I don't know, what objects are available through CreateObject and how can I use them? In bash I can try "help", "man", or in the worst case running the command with "--help" or "-h". Without even switching to a separate window with a help viewer or a browser. Most of the time some help will be there.

I think here lies the biggest problem: What if you have no idea what the command is to do something? The basic instinct would be to type the word corresponding to the action you're trying to do. If the command for that action isn't that word, the shell will usually just kick back an error that that command can't be found, not offer suggestions based upon the help files. If the help files were all content-indexed, the shell might be able to have the ability to go "The command you typed doesn't exist, but here's a list of commands that may be what you're looking for, type command --help to learn more"

spamcourt

@e4tmyl33t said:

I think here lies the biggest problem: What if you have no idea what the command is to do something? The basic instinct would be to type the word corresponding to the action you're trying to do. If the command for that action isn't that word, the shell will usually just kick back an error that that command can't be found, not offer suggestions based upon the help files. If the help files were all content-indexed, the shell might be able to have the ability to go "The command you typed doesn't exist, but here's a list of commands that may be what you're looking for, type command --help to learn more"

There's apropos. And the bash shell provides hooks so that the "command not found" error can trigger running a shell script which could for example do what you just described. It shouldn't be very hard to write something like that. There is a script which does something vaguely similar, and I think Ubuntu installs it by default.

gilhad

@e4tmyl33t said:

I'm not arguing that the CLI should be removed entirely. For power-users, it may entirely be necessary to use a CLI to do things that the GUI can't do readily...but there's no reason to nearly *mandate* CLI usage just to use or configure a machine, as a lot of Linux users tend to argue for on forums and the like. Any common activity that someone who's completely unfamiliar with the operating system may want to do should have an easily understandable GUI attached to it. A properly designed operating system should be able to be installed, configured, and ready to use by a complete newbie for everyday usage without ever seeing a CLI or needing someone to decipher any part of the interface.

I think, that it is way Linux is heading just now.

First there should be robust and powerfull base system, then there came some GUI and then the GUI gets more and more tools. As the base system is configured via text files, the GUI program can parse them, make some nice dilagos/menus from them and then write back what was changed. The undelying system really does not care, whether text file was generated by GUI program, or written in VIM (or generated from script by echo "something" >>file)

So there came first automated installers, then more sofisticated configuration tools, then GUI programs for all that. I had seen Linux distributions, that was installed and used just from GUI, without user even aware of CLI.

But GUI has its problems - if you want make something really configurable (sometimes to point of programmable, like say sed or awk), then there is too much of choises to fit on one screen and there is too much of combination, so even when you go by different paths, then there is a lot of dialogs and tons of text fields to fill, so you get something overcomplicated again. Or you loose a lot of functionality. Usually both.

So in my eyes, there should be to different areas - one easy, safe, GUI and limited for "newbies" and users, who does not care, just want to see playing kittens or write annual report or what. This should have some really limited (so not confusing) predefined administration.

The other area are more sofisticated tasks for people willing to learn difficult concepts in order to get done difficult, unusual and not pre-prepared tasks done. And that means something like CLI - or other IDE for programming. This area should not be confused with the sandbox mentioned earlier - here are different rules as it is mentioned for different kind of users and different tasks.

The problem is, that many users of the first kind thinks, that because they can click Next-Next-Finish and install some prepared programs in one of few pre-prepared configuration, that they are also skilled enought to use the other area the same way with the same level of sand-boxing - which simply is not true. It is the same as saying "because I made some HTML pages in Word and I was able to auto-upload them on web, I am perfectly skilled to write drivers in assembler - I just need some GUI interface like a ribbon from Word and I will be fine. I do not read about interrupts and RAM ranges and CPUs and such - there should be discoverable interface anyway. But this approach is not good. Computers are so complicated, that you just need to learn a lot to be able use them to fullness (or at least to some higher level). Abstractions are nice to enable you to do somthing right now, but they also inherently hides a lot of you, just to be easy to use. But computers are able to do not only easy tasks, but also complicated one.

boomzilla

@e4tmyl33t said:

I think here lies the biggest problem: What if you have no idea what the command is to do something? The basic instinct would be to type the word corresponding to the action you're trying to do. If the command for that action isn't that word, the shell will usually just kick back an error that that command can't be found, not offer suggestions based upon the help files. If the help files were all content-indexed, the shell might be able to have the ability to go "The command you typed doesn't exist, but here's a list of commands that may be what you're looking for, type command --help to learn more"

Yes, this is always a problem, and it's no better using a GUI. And sometimes a GUI is even more difficult, since obscure options are usually right there in the man page for CLI tools and accessible right there, as opposed to buried under multiple dialogs and tabs.

Snooder

@e4tmyl33t said:

I think here lies the biggest problem: What if you have no idea what the command is to do something? The basic instinct would be to type the word corresponding to the action you're trying to do. If the command for that action isn't that word, the shell will usually just kick back an error that that command can't be found, not offer suggestions based upon the help files. If the help files were all content-indexed, the shell might be able to have the ability to go "The command you typed doesn't exist, but here's a list of commands that may be what you're looking for, type command --help to learn more"

No, that is not the basic instinct. That the basic instinct for non-technical people who just poke at a system until it does something. Technical people know that the proper way to figure out what to do when you don't even know what command you want is to check a manual. Because having the system "suggest" commands to you is imprecise and will result in suggestions that may be entirely not what you want.

Let's take Blakey's problem with rename. Imagine that he didn't know any renaming command at all, and instead typed "name". Then the system "helpfully" suggested "rename" to him. He uses it, and it DOES NOT DO WHAT HE WANTS. Worse, he now believes that "rename" does something that it really doesn't do, and might continue to use the wrong command in the future. If, on the other hand, he had looked up a list of commands and read through them carefully, he would know that the command he needs to use is "mv" and know exactly it does. And that doesn't even get into other, more esoteric cases, where the command he thought he wanted isn't even remotely similar to the real command. He'd just get a list of completely unhelpful "suggestions" and still be no better off.

Which is fine for software intended for use by non-technical people. That's not what we have been talking about though. Instead we are talking about software intended for professional use by people who should be highly technical.

Here's an analogy. My dad has an entertainment system he paid a couple grand for. It came with a nifty "universal remote" that has a nice interface where you can setup some common activities and commands. Which is great because when he just wants to watch tv, he presses the "Watch TV" button, and it works. This is analogous to what your "inherently discoverable" interface would do. However, a few years back I had to connect my computer to the system so I could stream some movies. That's not in the remote. The remote doesn't even have the functionality needed to do this. Instead, I had to read the manual, figure out where to connect the computer to the AV receiver, figure out how to switch the AV receiver input, change the resolution on the TV, and fiddle with some other settings to get the sound and everything working right (Video and Audio came from different inputs). It would not have been helpful at all if the remote assumed that because I wanted to "watch movies" then the "Watch TV" would be close enough. So the remote is good for my dad's casual use, but useless to my specialized use case. Now, if the entertainment system wasn't in my dad's house, but was instead in some commercial center where new devices are plugged in and out on a daily basis with wildly different configurations, the universal remote would end up being practically worthless.

gilhad

@e4tmyl33t said:

You or I could make that distinction. What about Bob, the guy who's never sat in front of a computer in his life? If he goes to copy a file on a brand new computer, and doing so either requires said confusingly-named utilities or a terrible UI, what is he likely to blame for this? He won't say "Dammit, these programs make it so hard to use them!", he'll say "What is this <OS> shit? Why don't it work?"

Here is the root of it, I would say. Windows are targeted to such Bobs and they do a lot of work to actually hide nearly everything from them. And long time did not care for geeks.

Linux is targeted at geeks, who wants do everything what is possible with given HW and do not want to be restricted to some "easy and safe sandboxes". Geeks, who are willing pay the prize in terms of hours of learning, just to be able to do more with the computer. And long time did not care for Bobs.

(Well over time Windows released even something for geeks and Linux released something for Bobs, but the main audience is just totally different.)

I had seen 3-wheeled cars made by car company - they looked like cars and behaved like cars, just was smaler and lighter.

I had seen 3-wheeled motorcycles made by motorcyckle companies - they looked like motorcykles, just was more stable and massive.

Both was 3-wheeled vehicles, but was targeted on different audience and was totally different in construction. Windows on PC and Linux on PC are both such 3-wheeled vehicles now.

gilhad

@blakeyrat said:

How long have you spent learning VBScript or JScript or AppleScript?
Your argument doesn't boil down to "the CLI is better", it boils down to "I know the CLI better". That's different.

So you say, that VBScript or JScript are now GUI generated and not long buch for text in programming language? And you just need to click some menus and dialog and not to write some cryptic commands with parameters?

My argument was - There are some problems, which are much better managed by programming, then by clicking GUI.

I do not care, whether I program in bash, python, Javascript, Java or other language. Everytime I had to program something more complex, there was a lot of text and few of mouse clicking. There was a lot of calling programs/procedures/functions and such and very small of selecting radioboxes and checkboxes.

Or are you impling, I am programming in GUI, when open bunch of terminals on X and start typing in vim? Technically I am on GUI - I have pictures on background, I have mouse with nice arrow and all, but really I am programming some commands in text with parameters - and the result could be as well bash-script or python application with dilogs and menus - still I need to know, what does which command, and what parameters it takes.

HardwareGeek

@e4tmyl33t said:

@spamcourt said:
JScript or VBScript (not sure about AppleScript) would probably be much more cumbersome to type in an interactive shell. Besides, it's still a textual interface. Unix CLI wins over these just because it's more terse. And ironically, more discoverable. Where do I look up, I don't know, what objects are available through CreateObject and how can I use them? In bash I can try "help", "man", or in the worst case running the command with "--help" or "-h". Without even switching to a separate window with a help viewer or a browser. Most of the time some help will be there.

I think here lies the biggest problem: What if you have no idea what the command is to do something? The basic instinct would be to type the word corresponding to the action you're trying to do. If the command for that action isn't that word, the shell will usually just kick back an error that that command can't be found, not offer suggestions based upon the help files. If the help files were all content-indexed, the shell might be able to have the ability to go "The command you typed doesn't exist, but here's a list of commands that may be what you're looking for, type command --help to learn more"

This is something even I will admit could be vastly improved. If you know the command name, info or man will (usually) tell you everything you need to know to use it, but finding the name of the command if you don't already know it can be problematic.

In bash, help gets a list of bash builtin commands, but no help with any other tasks like cp or mv. In csh, all it gets is "help: Command not found."

apropos is what you probably want, but the name is completely non-obvious, and the output tends to be cluttered with irrelevant junk that happens to have the search string somewhere in the description. On my work system, "apropos rename" produces 81 results that include "Tcl_FSRenameFile," 4 different "rename" commands (rename (1), rename (2), rename (3p) and rename (n)) and a bunch of random cruft along with what you were probably looking for, "mv." And the one-line descriptions give no clue that you generally want to "move (rename) files" rather than "Rename files".

gilhad

@e4tmyl33t said:

I think here lies the biggest problem: What if you have no idea what the command is to do something? The basic instinct would be to type the word corresponding to the action you're trying to do. If the command for that action isn't that word, the shell will usually just kick back an error that that command can't be found, not offer suggestions based upon the help files. If the help files were all content-indexed, the shell might be able to have the ability to go "The command you typed doesn't exist, but here's a list of commands that may be what you're looking for, type command --help to learn more"

You mean something like

$ apropos rename|grep 1
dpkg-name            (1)  - rename Debian packages to full package names
git-mv               (1)  - Move or rename a file, a directory, or a symlink
rename               (1)  - rename files
zipnote              (1)  - write the comments in zipfile to stdout, edit comments and rename files in zipfile

where the grep 1 selects only lines with 1, which are executable commands. This feature is in Linux longer, than I know it.

FrostCat

@Cassidy said:

@e4tmyl33t said:
An OS should be inherently discoverable, at least in a useful world.

Why?

Almost anything should be discoverable, and the reason should be obvious enough that nobody should have had to answer. Do you like the idea of living in a world where everything fights you?

@Snooder said:

Let's take Blakey's problem with rename. Imagine that he didn't know any renaming command at all, and instead typed "name". Then the system "helpfully" suggested "rename" to him. He uses it, and it DOES NOT DO WHAT HE WANTS. Worse, he now believes that "rename" does something that it really doesn't do, and might continue to use the wrong command in the future. If, on the other hand, he had looked up a list of commands and read through them carefully, he would know that the command he needs to use is "mv" and know exactly it does.

Here's a possibility, rename is badly named and needs to be renamed to something more sane.
rename-all or bulk-rename seems like a good start.

By the way, just throwing this out there, but this is actually a plugin for the Thunar file manager:

esoterik

@blakeyrat said:

Exercise 1
Question: I have a file: ~/folder1/folder2/file.txt. I rename "folder1" to "poop". Has the name of file.txt changed?

If one has the perspective that the name of the file is where it can be found, yes its name is now '~/poop/folder2/file.txt' (hint: all absolute paths to the file are now broken!) The man file was presumably written by someone who know who came up with this shit (and might have held this same perspective on filenames), which is what you wanted to know in your OP. Sorry for answering your question.

@blakeyrat said:

You read my posts here, do you honestly think I'm retarded?

My point was the difference between pretending to be a retard, and being a retard is negligable. You either didn't comphrend what i wrote, or you are pretending not to comphrend what i wrote, either way any reply will appear to be from someone who didn't comphrehend what i wrote!

Oh and your supposed to know to type 'man' because that supposed to be one of the basics that you learn, like how DOS, and Windows CLI (CMD) had/have 'help.'

flabdablet

@e4tmyl33t said:

I'm not arguing that the CLI should be removed entirely. For power-users, it may entirely be necessary to use a CLI to do things that the GUI can't do readily...but there's no reason to nearly mandate CLI usage just to use or configure a machine, as a lot of Linux users tend to argue for on forums and the like.

I think this point is actually a bit of a furphy. I don't actually see a lot of Linux users arguing for mandatory use of a CLI for configuration; I have seen many arguments for continued availability of a CLI for that purpose, and a lot of proprietary software fanbois who wilfully misrepresent the latter position as the former for convenient construction of straw men.

The reason you'll see so many CLI-based solutions posted on Linux help forums is that it's far less time-consuming to write out three or four command lines and say "paste this into a terminal" than it is to do a full step-by-step GUI walkthrough with all necessary screenshots. Trying to communicate a moderately complex configuration task in the restricted language of point-and-grunt is like programming in Brainfuck. I'm sure some people enjoy it; I'm not one of them.

@flabdablet said:

The reason you'll see so many CLI-based solutions posted on Linux help forums is that it's far less time-consuming to write out three or four command lines and say "paste this into a terminal" than it is to do a full step-by-step GUI walkthrough with all necessary screenshots.

Ah, so pure laziness. Gotcha.
The way I see it is if a configuration task is sufficiently complex that you need to start using the CLI, then perhaps it's not that the CLI is better at configuring things but that the GUI tools are just really shit at it.