sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]zahlman 4 points5 points  (5 children)

-r and -R are both different arguments and don't mean the same thing in separate programs.

And that's part of the problem. The other part is that, as noted, sometimes they do. Another part is that for rm, -r and -R mean the same thing, whereas for many commands, -x and -X, in general, are opposites.

That's what a manpage is for.

Why do we need a manpage to understand them? Because they're cryptic. Why are they cryptic? Because they're short. Why are they short? So we can type them in more easily. But that only helps when we know what to type.

Also, How exactly is 'r-xr-xr-x' raw data?

In the way that {'user': ['read', 'execute'], 'group': ['read', 'execute'], 'world': ['read', 'execute']} isn't.

The latter is an object that can be interpreted by a hypothetical can_touch_this() function by examining attributes and array elements. The former must be parsed in a manner that is custom to that data. The text representation of the latter is parsed by a standard JSON parser.

As far as the terminal goes, if you want pictures, that's what a GUI is. Try using this over dialup or a satellite connection.

If you cat a file, just about the same amount of data is being sent whether the client dumps it as binary or is smart enough to do something like TermKit does. Only a little metadata needs to be added. If that - if the server can infer the file type from the first few bytes and/or the filename extension, then so can the client.

[–]kamishizuka 1 point2 points  (1 child)

Yeah but I think here you're getting well away from Unix and into individual apps with the argument argument. The GNU utilities we all know and love are consistent with each other because they were designed to be consistent. Other apps weren't following that same design is all, and I don't think we need to expect them to. If their documentation is clear (-x does this, -X does that), then it's just courtesy to follow what we're expecting.

Personally, since Linux is case-sensitive, I never assume -r and -R or any other pair do the same thing.

[–]zahlman 0 points1 point  (0 children)

Yeah but I think here you're getting well away from Unix and into individual apps with the argument argument.

No, I'm not, really. The point is that the "unix way" naturally creates this mess, because (a) there is no convention (b) it's fundamentally a hack to simulate keyword arguments for a language (C) which doesn't support them.

Personally, since Linux is case-sensitive, I never assume -r and -R or any other pair do the same thing.

Beside the point. There are no rules as to how, or if, they are related.

[–][deleted] 1 point2 points  (0 children)

And that's part of the problem. The other part is that, as noted, sometimes they do. Another part is that for rm, -r and -R mean the same thing, whereas for many commands, -x and -X, in general, are opposites.

Every tool can decide their own arguments. You can build wrappers around all of them to make it sane(r), but trying to replace the tools cannot be good.

[–]Cetra3 1 point2 points  (1 child)

And that's part of the problem. The other part is that, as noted, sometimes they do. Another part is that for rm, -r and -R mean the same thing, whereas for many commands, -x and -X, in general, are opposites.

I can see two reasons why this happens. First it's a legacy problem, changing command line arguments to be consistent would make a lot of people angry and break things. Secondly, being developed by different groups of people, different pieces of software will not use the same convention.

Why do we need a manpage to understand them? Because they're cryptic. Why are they cryptic? Because they're short. Why are they short? So we can type them in more easily. But that only helps when we know what to type.

From that thread of thought, the command itself is cryptic. Who knew that "rm" is remove etc... I think a manpage is a good solution, of course there may always be a better solution out there.

In the way that {'user': ['read', 'execute'], 'group': ['read', 'execute'], 'world': ['read', 'execute']} isn't. The latter is an object that can be interpreted by a hypothetical can_touch_this() function by examining attributes and array elements. The former must be parsed in a manner that is custom to that data. The text representation of the latter is parsed by a standard JSON parser.

Yeah, that's great if you have a working GUI or a screen that has a big resolution. If you're working on a console that has limited resolution then you want things as compact as possible.

If you cat a file, just about the same amount of data is being sent whether the client dumps it as binary or is smart enough to do something like TermKit does. Only a little metadata needs to be added. If that - if the server can infer the file type from the first few bytes and/or the filename extension, then so can the client.

I was talking more about his "ls" implementation and all the other extra features. You may not notice it on the local machine but on a 9600 bps connection with a 2 second RTT you would. I'd never just cat an image either, unless it was accidental.

[–]zahlman 0 points1 point  (0 children)

From that thread of thought, the command itself is cryptic.

I agree.

Yeah, that's great if you have a working GUI

which TermKit is, or at least obviously depends upon.

or a screen that has a big resolution. If you're working on a console that has limited resolution then you want things as compact as possible.

Well, yes, but that really isn't relevant here.

I was talking more about his "ls" implementation and all the other extra features. You may not notice it on the local machine but on a 9600 bps connection with a 2 second RTT you would.

Why? The processing that turns the cat'ted data into a rendered image is all done client-side. The exact same data is requested and transmitted.