[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Shells, Mplayer and Security (WAS: X Accessibility ...)



Andor Demarteau wrote:
no codecs are only used for compress/decompress audio/videio in/output
even for the Video4Linux stuff.
i didn't know that. Well, I ment what I'd call effects, plugs that modify their input in stead of just converting it.

sox that also does file-conversion.
Sounds a bit tricky. Isn't sox also some firewall thingy?

mplayer has -speed option but I'm not sure if it will go over
1.0 (normal) speed.
Umm speaking of MPlayer, doesn't it also have a GTK1 interface or am I totally mistaken? Also, does this option only affect pitch. In Winamp I've got a true time-stretching plug-in that rather than altering the playback rate, actually lengthens or shortens the sample without touching the pitch at all. The minimum is 50 percent of the original.

Smetimes shorthand versions are available, quite handy.
I can believe that. Still, isn't apt-get install a bit illogical, wouldn't apt-get --install (with two dashes before the word install) be more like a conventional long option? Well, it was much worse than this in the DOS days. Although MS progs used the slash switch convention, some 3rd party apps used a dash in stead.

i.e. if you only give apt* access, the user can't change the
root-passowrd.
And if he or she stops apt, will all of his other processes still run with normal permissions? Also, if someone is running something as root, does root show up in the user list then?

yes and get the benefit of the free stuff to use in there own
commerical project called SunOS :)
I thought something like that would be the case, too. As they are a firm making money after all. Umm yet another ASCII smiley, it would have gone unnoticed with speech if I hadn't accidentally looked at end of sentence to discover it with magnification.

pff. ambiguous?
Yes, definitely. I've always disliked this aspect in Unix and in C-programs as well for that matter. Short names are bad for a variety of reasons:

Firstly, my personal opinion is that like hyperlink names, command-names should be relatively context-free. AS long as the user knows what he or she wants to do, finding the right command in the list of commands should be easy without the manual. Even such a fundamental command as cd is an excellent example. If I knew computers but didn't knew any Unix or DOS and was confronted with a command list. I'd guess that cd would play, rip or navigate ddata or audio CDs. The same thing applies to man, it could mean a dozwen things including something to do with managing or management. And the first association to me is simply the English word man. Only if it was a file extension, I might mentally extrapolate it to manual. Come on, man in stead of manual, is typing three extra letters too much. I think the command should be named help, as that is what most users will try sooner or later.

As a programming example, setPreferrableScrollableViewportSIze, in Swing, is pretty clear. If this was C the thing would be something like spsvps, I suppose (well not quite but almost). Also in C plus plus the vector method empty is quite ambiguous. Is this an imperative about emptying the vector or a boolean style query about whether the thing is empty. The Java equivalent is called isEmpty, which resolves the issue cleanly again.

Secondly, though some claim that short names are faster to type, this matters very little in the end to me. Using any more complicated shell commands, or programming, is mainly logical mental work in stead of a typing contest.

Thirdly and finally, shortening names drops their mnemonicness considerably. Take umount for instance, it might well be unmount or umnt, depending on who did the abbreviation work. This makes it harder to remember things in the end. Heck even DOS names are often friendlier than their Unix counterparts, though DOs had the 8.3 file limit which Unix has never had as far as I know.

End of mini rant.

Ideally, I'd want a shell that shatters the myth that command-line Oses are supposed to be "difficult". A shell could be considerably more friendlier than Unix or DOS is, with a bit of polite helping, hand-holding and instructions to new users (like this is your first time in blablabla. Type in help to get a list of commands you can use.). Well, it might not be as powerful as average Unix thingies but something more powerful than DOS is certainly easy. Even in Win XP there's no equivalent of wc. And modern batch programming is nasty 70s style goto jumping and looping at best.

- make symlinks with these names
Generally, won't be doing this. The reason is that it is no use to complain about these things really, unless I'm attempting to write a newbie shell some day, as I have to use the short names on someone else's system anyway. I think I'll do two symlibks though. Cls to clear (both are pretty ambiguous but I've gotten used to cls. The other thing would name ln as link and swap the first two parameters. Conceptually, I tend to think of what link I'm creating first in stead of the thing being linked to, though logically the operation is like cp.

- make aliases in your shells rc-file.
Are aliases shell specific? I tend to think of the word alias in the Mac sense.

You could look at tclsh in which you can use tcl-statements, but AFAIK
nothing exists in the range you want.
How's TCL like? I've been hearing good stuff about zsh so I'll consider that as well.

perl was created with regexp in mind and a sole
goal.
True, still I find the Java regexp implementation a bit clunky. It could be made easier in C plus plus with sensible operator overloads.

--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and more:
http://www.student.oulu.fi/~vtatila


Reply to: