Shell commands like to OS/2 shell (or MS PowerShell)

[Slava Zanko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folk,

I want to propose new idea about names of command line utilites...

For example, all present utilites have sence just for guru's (ls, rm,
fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
(shell aliasing) these and much more utilz to another names? Like to:

ls -> filesystem.list
rm -> filesystem.remove
fsck.* -> filesystem.check.*
mkfs.* -> filesystem.make.*
convert -> media.convert.image
mencoder -> media.convert.video
oggenc -> media.convert.audio.ogg
mplayer -> media.player.*

etc

This idea will be easy to realize (need to make at first time one rpm
package with lot of symlinks... and then long-time work in all present
rpm-packages for respect this technology). But we need for
standartization of alias names... in ideal case, standartization must
touch all distros (new standard?)

P.S. This not my idea. Originally from:
http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...

Thanks for attention.

- -- 
WBR, Slavaz.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvM3mYACgkQb3oGR6aVLppnNQCeNDVZS37Y3/J7nBrsXDMM32rN
> H48An1dWzW/TKGzcrIZ7pPZjaehEO9mm
> =iD/i
> -----END PGP SIGNATURE-----

[Ryan Rix]

On Mon 19 April 2010 3:51:23 pm Slava Zanko wrote:
> Hi folk,
>
> I want to propose new idea about names of command line utilites...
>
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> (shell aliasing) these and much more utilz to another names? Like to:
>
> ls -> filesystem.list
> rm -> filesystem.remove
> fsck.* -> filesystem.check.*
> mkfs.* -> filesystem.make.*
> convert -> media.convert.image
> mencoder -> media.convert.video
> oggenc -> media.convert.audio.ogg
> mplayer -> media.player.*
>
> etc
>
> This idea will be easy to realize (need to make at first time one rpm
> package with lot of symlinks... and then long-time work in all present
> rpm-packages for respect this technology). But we need for
> standartization of alias names... in ideal case, standartization must
> touch all distros (new standard?)
>
> P.S. This not my idea. Originally from:
> http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
> eotf=1&u=http%3A%2F%2Fwww.linux.org.ru%2Fforum%2Ftalks%2F4797323&sl=ru&tl=e
> n
>
> Thanks for attention.

I'm against making a mess of PATH with a crapload of symlinks. 
If this were to happen, it should happen at a bashrc alias level, and even 
then I'm still against it.

[Athmane Madjoudj]

> I'm against making a mess of PATH with a crapload of symlinks.
> If this were to happen, it should happen at a bashrc alias level, and even
> then I'm still against it.

i agree, also the proposed commands are too long to be typed in the terminal.

they look like name-spaces in a programming language

Best regards

[Athmane Madjoudj]

> i agree, also the proposed commands are too long to be typed in the terminal.
>
> they look like name-spaces in a programming language
>
> Best regards

Maybe PASH is what you are searching: http://pash.sourceforge.net/

[Thomas Janssen]

On Tue, Apr 20, 2010 at 1:39 AM, Athmane Madjoudj  wrote:
> > I'm against making a mess of PATH with a crapload of symlinks.
> > If this were to happen, it should happen at a bashrc alias level, and even
> > then I'm still against it.
>
> i agree, also the proposed commands are too long to be typed in the terminal.
>
> they look like name-spaces in a programming language

Agreed. Plus a command like: filesystem.remove would confuse and scare
novices. "Ugh, that removes my filesystem"

[Kevin Kofler]

Thomas Janssen wrote:
> Agreed. Plus a command like: filesystem.remove would confuse and scare
> novices. "Ugh, that removes my filesystem"

Well, if it scares them enough not to abuse rm -rf, that's a good thing. ;-) 
IMHO file deletions should always be performed through a graphical file 
manager with confirmation prompts. The GUI also reduces the risk of typos by 
a lot.

Kevin Kofler

[Pavel Alexeev]

20.04.2010 03:29, Ryan Rix пишет:
> On Mon 19 April 2010 3:51:23 pm Slava Zanko wrote:
> > Hi folk,
> >
> > I want to propose new idea about names of command line utilites...
> >
> > For example, all present utilites have sence just for guru's (ls, rm,
> > fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> > (shell aliasing) these and much more utilz to another names? Like to:
> >
> > ls ->  filesystem.list
> > rm ->  filesystem.remove
> > fsck.* ->  filesystem.check.*
> > mkfs.* ->  filesystem.make.*
> > convert ->  media.convert.image
> > mencoder ->  media.convert.video
> > oggenc ->  media.convert.audio.ogg
> > mplayer ->  media.player.*
> >
> > etc
> >
> > This idea will be easy to realize (need to make at first time one rpm
> > package with lot of symlinks... and then long-time work in all present
> > rpm-packages for respect this technology). But we need for
> > standartization of alias names... in ideal case, standartization must
> > touch all distros (new standard?)
> >
> > P.S. This not my idea. Originally from:
> > http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
> > eotf=1&u=http%3A%2F%2Fwww.linux.org.ru%2Fforum%2Ftalks%2F4797323&sl=ru&tl=e
> > n
> >
> > Thanks for attention.
>
> I'm against making a mess of PATH with a crapload of symlinks.
> If this were to happen, it should happen at a bashrc alias level, and even
> then I'm still against it.

I also against making it global by default. But this can be done in 
separate folder, not to standard /usr/bin, and then added for users who 
want it just add it into PATH.
I not sure what I want it, but sometimes really hard understand by name 
what do command and from which area it is.

[drago01]

On Tue, Apr 20, 2010 at 2:55 PM, Pavel Alexeev (aka Pahan-Hubbitus)
 wrote:
> 20.04.2010 03:29, Ryan Rix пишет:
> > On Mon 19 April 2010 3:51:23 pm Slava Zanko wrote:
> > > Hi folk,
> > >
> > > I want to propose new idea about names of command line utilites...
> > >
> > > For example, all present utilites have sence just for guru's (ls, rm,
> > > fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> > > (shell aliasing) these and much more utilz to another names? Like to:
> > >
> > > ls ->  filesystem.list
> > > rm ->  filesystem.remove
> > > fsck.* ->  filesystem.check.*
> > > mkfs.* ->  filesystem.make.*
> > > convert ->  media.convert.image
> > > mencoder ->  media.convert.video
> > > oggenc ->  media.convert.audio.ogg
> > > mplayer ->  media.player.*
> > >
> > > etc
> > >
> > > This idea will be easy to realize (need to make at first time one rpm
> > > package with lot of symlinks... and then long-time work in all present
> > > rpm-packages for respect this technology). But we need for
> > > standartization of alias names... in ideal case, standartization must
> > > touch all distros (new standard?)
> > >
> > > P.S. This not my idea. Originally from:
> > > http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
> > > eotf=1&u=http%3A%2F%2Fwww.linux.org.ru%2Fforum%2Ftalks%2F4797323&sl=ru&tl=e
> > > n
> > >
> > > Thanks for attention.
> >
> > I'm against making a mess of PATH with a crapload of symlinks.
> > If this were to happen, it should happen at a bashrc alias level, and even
> > then I'm still against it.
>
> I also against making it global by default. But this can be done in
> separate folder, not to standard /usr/bin, and then added for users who
> want it just add it into PATH.
> I not sure what I want it, but sometimes really hard understand by name
> what do command and from which area it is.

That is what man command is for ...

[Slava Zanko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

drago01 wrote:
> > I also against making it global by default. But this can be done
> > in separate folder, not to standard /usr/bin, and then added for
> > users who want it just add it into PATH.

Yep, of course. This idea unobtrusive and don't hard for realization,
but much harder for standartization between people (and distros) :)
> > I not sure what I want it, but sometimes really hard understand
> > by name what do command and from which area it is.
>
> That is what man command is for ...

Sometime I know what I want, but I don't know is standart utility
present for this.
For example, I need for grep'ing some user from users list on my host.
How do it with 'man' utility? How I should guess about 'getent
passwd'? and what records more readable:

test $(getent passwd| grep -c '^someuser:') -eq 0 && useradd someuser
or
test $(system.user.list| grep -c '^someuser:') -eq 0 &&
system.user.add someuser

getent group | grep '^somegroup:'
or
system.group.list | grep '^someuser:'

For guru's of course much readable first variant :)

Or in additional we may have aliases for:

editor.txt => <your preferred editor>

editor.txt.sed => /usr/bin/sed
editor.txt.vim => /usr/bin/vim
editor.txt.joe => ...
editor.txt.gedit
editor.txt.kwrite
editor.img.gimp
editor.sound.guitar-newbie
etc

what happens after edit<tab>? You'll see 'editor'. Type 't' and press
<tab>. Press <enter> key for start preferred editor or just press
<tab> key again and you'll see editors (and only editors). Of course,
some utilities may present in few categories... And of course, my
names of programs just for example.

- --
WBR, Slavaz.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFLzat7b3oGR6aVLpoRAvtbAJ0dMLqtmIk0RujlCRYirDldui5s8wCggl5m
> +FxH9JZo7L03ByFaEkWknGc=
> =+Bfp
> -----END PGP SIGNATURE-----

[Muayyad AlSadi]

why do I smell COBOL ?

[Chris Tyler]

On Tue, 2010-04-20 at 01:51 +0300, Slava Zanko wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folk,
>
> I want to propose new idea about names of command line utilites...
>
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> (shell aliasing) these and much more utilz to another names? Like to:
>
> ls -> filesystem.list
> rm -> filesystem.remove
> fsck.* -> filesystem.check.*
> mkfs.* -> filesystem.make.*
> convert -> media.convert.image
> mencoder -> media.convert.video
> oggenc -> media.convert.audio.ogg
> mplayer -> media.player.*
>
> etc
>
> This idea will be easy to realize (need to make at first time one rpm
> package with lot of symlinks0007684a-0010long-time work in all present
> rpm-packages for respect this technology). But we need for
> standartization of alias names... in ideal case, standartization must
> touch all distros (new standard?)
>
> P.S. This not my idea. Originally from:
> http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
>
> Thanks for attention.

Actually, that's not a completely new idea -- Multics used links in
exactly this fashion decades ago, so that you could type the long or
short version of command names:

list                        ls
change_wdir                 cwd
print_wdir                  pwd
print_attach_table          pat
last_message_time           lmt
...etc...

However, the long names fell into disuse quickly, because ... no one
wants to type that much. I can almost guarantee the same thing would
happen now.

If you wanted to implement this, I would recommend using aliases rather
than symlinks. This is Open Source -- give it a whirl and see how you
like it, and if you do, then package it up and see whether its useful to
others.

-Chris

[Adam Williamson]

On Tue, 2010-04-20 at 01:51 +0300, Slava Zanko wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folk,
>
> I want to propose new idea about names of command line utilites...
>
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> (shell aliasing) these and much more utilz to another names? Like to:
>
> ls -> filesystem.list
> rm -> filesystem.remove
> fsck.* -> filesystem.check.*
> mkfs.* -> filesystem.make.*
> convert -> media.convert.image
> mencoder -> media.convert.video
> oggenc -> media.convert.audio.ogg
> mplayer -> media.player.*
>
> etc
>
> This idea will be easy to realize (need to make at first time one rpm
> package with lot of symlinks... and then long-time work in all present
> rpm-packages for respect this technology). But we need for
> standartization of alias names... in ideal case, standartization must
> touch all distros (new standard?)
>
> P.S. This not my idea. Originally from:
> http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
>
> Thanks for attention.

This is something you don't need anyone's permission to implement. You
can simply implement it as a bunch of aliases defined in a file
in /etc/profile.d - see /etc/profile.d/colorls.sh for an example - and
then make a package with your file in it.

[Michał Piotrowski]

Hi,

2010/4/20 Slava Zanko :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folk,
>
> I want to propose new idea about names of command line utilites...
>
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> (shell aliasing) these and much more utilz to another names? Like to:
>
> ls -> filesystem.list
> rm -> filesystem.remove
> fsck.* -> filesystem.check.*
> mkfs.* -> filesystem.make.*
> convert -> media.convert.image
> mencoder -> media.convert.video
> oggenc -> media.convert.audio.ogg
> mplayer -> media.player.*
>
> etc

I really don't know why I like this idea... seems to be pretty cool.

I wouldn't use it day to day shall use, but it could be IMHO useful in
shell scripts when:
- it will be implemented in all unix os'es
- it will standardize program parameters

Let's imagine such situation - you need to write portable shell script
(I know "portable" and "shell script" is a bad joke ;)) across many
os'es:
- on OS A you need to use program foo with flag --bar
- on OS B you need to use program bas with --foo flag

It could be standarised with
do.that.thing --most-popular-flag-that-do-the-trick
> This idea will be easy to realize (need to make at first time one rpm
> package with lot of symlinks... and then long-time work in all present
> rpm-packages for respect this technology). But we need for
> standartization of alias names... in ideal case, standartization must
> touch all distros (new standard?)
>
> P.S. This not my idea. Originally from:
> http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
>
> Thanks for attention.
>
> WBR, Slavaz.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvM3mYACgkQb3oGR6aVLppnNQCeNDVZS37Y3/J7nBrsXDMM32rN
> H48An1dWzW/TKGzcrIZ7pPZjaehEO9mm
> =iD/i
> -----END PGP SIGNATURE-----
>
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel

On Tue, 2010-04-20 at 02:06 +0200, Michał Piotrowski wrote:
> Hi,
>
> 2010/4/20 Slava Zanko :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi folk,
> >
> > I want to propose new idea about names of command line utilites...
> >
> > For example, all present utilites have sence just for guru's (ls, rm,
> > fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> > (shell aliasing) these and much more utilz to another names? Like to:
> >
> > ls -> filesystem.list
> > rm -> filesystem.remove
> > fsck.* -> filesystem.check.*
> > mkfs.* -> filesystem.make.*
> > convert -> media.convert.image
> > mencoder -> media.convert.video
> > oggenc -> media.convert.audio.ogg
> > mplayer -> media.player.*
> >
> > etc
>
> I really don't know why I like this idea... seems to be pretty cool.
>
> I wouldn't use it day to day shall use, but it could be IMHO useful in
> shell scripts when:
> it will be implemented in all unix os'es
> it will standardize program parameters
>
> Let's imagine such situation - you need to write portable shell script
> (I know "portable" and "shell script" is a bad joke ;)) across many
> os'es:
> on OS A you need to use program foo with flag --bar
> on OS B you need to use program bas with --foo flag
>
> It could be standarised with
> do.that.thing --most-popular-flag-that-do-the-trick

Woudn't work, everyone would want their own standard. Again.

Also with these really long names, by the time you're finished typing a
command (and fixing all the typos), you have forgotten why you wanted to
do it.
> > This idea will be easy to realize (need to make at first time one rpm
> > package with lot of symlinks... and then long-time work in all present
> > rpm-packages for respect this technology). But we need for
> > standartization of alias names... in ideal case, standartization must
> > touch all distros (new standard?)
> >
> > P.S. This not my idea. Originally from:
> > http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
> >
> > Thanks for attention.
> >
> > WBR, Slavaz.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAkvM3mYACgkQb3oGR6aVLppnNQCeNDVZS37Y3/J7nBrsXDMM32rN
> > H48An1dWzW/TKGzcrIZ7pPZjaehEO9mm
> > =iD/i
> > -----END PGP SIGNATURE-----
> >
> > devel mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/devel

[Michał Piotrowski]

2010/4/20 Bernd Stramm :
> On Tue, 2010-04-20 at 02:06 +0200, Michał Piotrowski wrote:
> > Hi,
> >
> > 2010/4/20 Slava Zanko :
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Hi folk,
> > >
> > > I want to propose new idea about names of command line utilites...
> > >
> > > For example, all present utilites have sence just for guru's (ls, rm,
> > > fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> > > (shell aliasing) these and much more utilz to another names? Like to:
> > >
> > > ls -> filesystem.list
> > > rm -> filesystem.remove
> > > fsck.* -> filesystem.check.*
> > > mkfs.* -> filesystem.make.*
> > > convert -> media.convert.image
> > > mencoder -> media.convert.video
> > > oggenc -> media.convert.audio.ogg
> > > mplayer -> media.player.*
> > >
> > > etc
> >
> > I really don't know why I like this idea... seems to be pretty cool.
> >
> > I wouldn't use it day to day shall use, but it could be IMHO useful in
> > shell scripts when:
> > it will be implemented in all unix os'es
> > it will standardize program parameters
> >
> > Let's imagine such situation - you need to write portable shell script
> > (I know "portable" and "shell script" is a bad joke ;)) across many
> > os'es:
> > on OS A you need to use program foo with flag --bar
> > on OS B you need to use program bas with --foo flag
> >
> > It could be standarised with
> > do.that.thing --most-popular-flag-that-do-the-trick
>
> Woudn't work, everyone would want their own standard. Again.

True
> Also with these really long names, by the time you're finished typing a
> command (and fixing all the typos), you have forgotten why you wanted to
> do it.

Indeed :)
> > > This idea will be easy to realize (need to make at first time one rpm
> > > package with lot of symlinks... and then long-time work in all present
> > > rpm-packages for respect this technology). But we need for
> > > standartization of alias names... in ideal case, standartization must
> > > touch all distros (new standard?)
> > >
> > > P.S. This not my idea. Originally from:
> > > http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-...
> > >
> > > Thanks for attention.
> > >
> > > WBR, Slavaz.
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.10 (GNU/Linux)
> > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> > >
> > > iEYEARECAAYFAkvM3mYACgkQb3oGR6aVLppnNQCeNDVZS37Y3/J7nBrsXDMM32rN
> > > H48An1dWzW/TKGzcrIZ7pPZjaehEO9mm
> > > =iD/i
> > > -----END PGP SIGNATURE-----
> > >
> > > devel mailing list
> > > [e-mail]
> > > https://admin.fedoraproject.org/mailman/listinfo/devel
>
> --
> No amount of shouting at the round earth will make it flat.
>
> --
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel

[Frank Murphy]

On 19/04/10 23:51, Slava Zanko wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folk,
>
> I want to propose new idea about names of command line utilites...
>
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use.

Bookmark this:
http://ss64.com/bash/

Less typing, less for novices to forget.

[Slava Zanko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Murphy wrote:
> Bookmark this: http://ss64.com/bash/

I know about :) This idea just try for standartization of command
names... I know about posix and LSB,  but these standards  don't make
logic in the names of commands. Okay, as I see, this idea  don't have
interest for most...

To All: in any case, thanks for attention.

- --
WBR, Slavaz.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFLzVDzb3oGR6aVLpoRAuIcAJ4qqkjvdiJrI/HugEK9igYKMrdFFACePVrB
> XpjNndoiHl0fgk44C/SGIK8=
> =tyjV
> -----END PGP SIGNATURE-----

[Brian Wheeler]

On Tue, 2010-04-20 at 10:00 +0300, Slava Zanko wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Frank Murphy wrote:
> > Bookmark this: http://ss64.com/bash/
>
> I know about :) This idea just try for standartization of command
> names... I know about posix and LSB,  but these standards  don't make
> logic in the names of commands. Okay, as I see, this idea  don't have
> interest for most...
>
> To All: in any case, thanks for attention.

Honestly it doesn't effect me since my brain has long since been molded
into the unix way, but what about this as an alternative idea:

In addition to dumping out options when --help is specified, perhaps an
option like --helpxml could be added (maybe even generated from the gnu
getopts data) to dump out information about how the program is used as
well as the options.  Then a gui tool or other front end could parse
that XML and generate an interface for the end users.  AIX (I think)
used to have that for some of the more esoteric sysadmin tools, but they
were one-off wrappers.  It might make it easier for some people to build
complex command lines that use lots of piping...say for parsing logs or
something:

gunzip -fc /www/logs/access* | grep "GET /status" | cut -f 1 -d\  | sort
| uniq -c | sort -n

Or, even as a worst case, perhaps man pages could be parsed, but that is
probably a road to madness.

Brian
> WBR, Slavaz.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFLzVDzb3oGR6aVLpoRAuIcAJ4qqkjvdiJrI/HugEK9igYKMrdFFACePVrB
> XpjNndoiHl0fgk44C/SGIK8=
> =tyjV
> -----END PGP SIGNATURE-----

[Chris Jones]

> > On Tue, Apr 20, 2010 at 4:37 PM, Frank Murphy  wrote:
> On 19/04/10 23:51, Slava Zanko wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi folk,
> >
> > I want to propose new idea about names of command line utilites...
> >
> > For example, all present utilites have sence just for guru's (ls, rm,
> > fsck etc), but for novies it's hard to use.
>
> Bookmark this:
> http://ss64.com/bash/
>
> Less typing, less for novices to forget.
>
> --
> Regards,
>
> Frank Murphy
> UTF_8 Encoded, Fedora.x86 64-32 Hybrid

********************************************

I'm against any change. It makes perfect sense the way it is now. And it's
great for those who use both Linux and Unix because most commands are
interoperable between the two platforms. And beyond that, it's fast as a
result of keeping commands short and easy to remember.

I haven't met a newbie yet that is even interested in learning how to
interact with the command-line. They all seem to be some new breed migrating
from Windows and expecting *nix to operate in a 1:1 manner. And for those
who do want to learn it, do exactly that--learn it. It just takes time. Be
patient.

I think there's more important things to focus on regarding Linux
development.

[Steven James Drinnan]

On Wed, 2010-04-21 at 09:33 +1000, Chris Jones wrote:
> > > On Tue, Apr 20, 2010 at 4:37 PM, Frank Murphy
>
> wrote:
>         On 19/04/10 23:51, Slava Zanko wrote:
>         > -----BEGIN PGP SIGNED MESSAGE-----
>         > Hash: SHA1
>         >
>         > Hi folk,
>         >
>         > I want to propose new idea about names of command line
>         utilites...
>         >
>         > For example, all present utilites have sence just for guru's
>         (ls, rm,
>         > fsck etc), but for novies it's hard to use.
>     Bookmark this:
>     http://ss64.com/bash/
>
>     Less typing, less for novices to forget.
>
>     --
>     Regards,
>
>     Frank Murphy
>     UTF_8 Encoded, Fedora.x86 64-32 Hybrid
>
>
>
>
> I'm against any change. It makes perfect sense the way it is now. And
> it's great for those who use both Linux and Unix because most commands
> are interoperable between the two platforms. And beyond that, it's
> fast as a result of keeping commands short and easy to remember.
>
> I haven't met a newbie yet that is even interested in learning how to
> interact with the command-line. They all seem to be some new breed
> migrating from Windows and expecting *nix to operate in a 1:1 manner.
> And for those who do want to learn it, do exactly that--learn it. It
> just takes time. Be patient.

+1
> I think there's more important things to focus on regarding Linux
> development.
>
> -- 
> Chris Jones
> Photographic Imaging Professional and Graphic Designer
> ABN: 98 317 740 240

Basically MS introduced PowerShell to compete with bash and try to give
Windows some flexibility like Linux (The syntax is now almost the same).
Remember this is for power-users, and newbies do not want the hassle of
using the commandline.

Bash is a powerful tool and there maybe some flaws in the way that it
can be used but is it worth a rewrite?

[drago01]

On Tue, Apr 20, 2010 at 12:51 AM, Slava Zanko  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folk,
>
> I want to propose new idea about names of command line utilites...
>
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> (shell aliasing) these and much more utilz to another names? Like to:
>
> ls -> filesystem.list
> rm -> filesystem.remove
> fsck.* -> filesystem.check.*
> mkfs.* -> filesystem.make.*
> convert -> media.convert.image
> mencoder -> media.convert.video
> oggenc -> media.convert.audio.ogg
> mplayer -> media.player.*
>
> etc

Sounds like a waste of time ...

[Alexander Boström]

tis 2010-04-20 klockan 01:51 +0300 skrev Slava Zanko:
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> (shell aliasing) these and much more utilz to another names?

The present utilities makes sense for gurus because they understand the
history behind them and why the utilities have become what they are. But
to create something that's easy for new users and that might be
attractive to those of us that already know our way around the shell it
wouldn't be enough to rename the commands. You'd need to dig deeper.

For example you still have lots of obscure switches and options to
consider. (Why is media.convert.video nothing at all like
media.convert.audio.ogg?) And you have fun things like string quoting,
forking processes, vectors (say, the difference between "$*" and "$@"),
$IFS, error handling (did you know about "set -e"?) and so on...

/Alexander

On Tue, 2010-04-20 at 16:56 +0200, Alexander Boström wrote:
> tis 2010-04-20 klockan 01:51 +0300 skrev Slava Zanko:
> > For example, all present utilites have sence just for guru's (ls, rm,
> > fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> > (shell aliasing) these and much more utilz to another names?
>
> The present utilities makes sense for gurus because they understand the
> history behind them and why the utilities have become what they are. But
> to create something that's easy for new users and that might be
> attractive to those of us that already know our way around the shell it
> wouldn't be enough to rename the commands. You'd need to dig deeper.
>
> For example you still have lots of obscure switches and options to
> consider. (Why is media.convert.video nothing at all like
> media.convert.audio.ogg?) And you have fun things like string quoting,
> forking processes, vectors (say, the difference between "$*" and "$@"),
> $IFS, error handling (did you know about "set -e"?) and so on...
>
> /Alexander

In addition to all that, I wouldn't say that these composite names are
all that memorable. You would get people add a layer of translation to
polish, chinese and to australian english. Then you would get shell
scripts relying on translation layers being present. Romanian and French
language purists would insist that filesystem.do.this.and.that should be
that.and.this.do.filesystem, nothing else will do.
>

[Kevin Kofler]

Slava Zanko wrote:
> For example, all present utilites have sence just for guru's (ls, rm,
> fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> (shell aliasing) these and much more utilz to another names?

No. It's a quite silly idea.
1. Those tools have been called like that for years, everything and everyone 
uses those names. Those aliases would just cause compatibility issues while 
they're phased in and solve nothing.
2. As already pointed out by others, the aliases are too long to type in.
3. As already pointed out by others, this would still not solve the problem 
of switches and their consistency.
4. As already pointed out by others, you'll have an extremely hard time 
getting everyone to agree on a standard naming.
5. IMHO, that kind of users should not be using the terminal in the first 
place, it's what GUIs are for. The terminal should only be used by those 
users who know how to use it efficiently, and terse, quickly-typed command 
names are part of that. Heck, even experienced users are often better off 
with a GUI.

Kevin Kofler

[Frank Murphy]

On 21/04/10 07:00, Kevin Kofler wrote:
> Slava Zanko wrote:
> > For example, all present utilites have sence just for guru's (ls, rm,
> > fsck etc), but for novies it's hard to use. Is good idea to symlink'ing
> > (shell aliasing) these and much more utilz to another names?

--snip--
> IMHO, that kind of users should not be using the terminal in the first
>
> place, it's what GUIs are for.

+1