From: Horst von Brand <hidden> Date: 2016-06-15 22:42:05
Junio C Hamano [off-list ref] wrote:
Horst von Brand [off-list ref] writes:
quoted
quoted
3. Non-binaries are called '*-scripts'.
In earlier discussions some people seem to like the
distinction between *-script and others; I did not
particularly like it, but I am throwing this in for
discussion.
quoted
I for one think this makes the command name dependent on a non-essential
implementation detail, so -script should go.
I had the same opinion. The counter-argument people raised when
this topic came up on the list was that it would help grepping
in the source tree.
Grepping for what?
It is not /that/ much more expensive to run file(1) over the tree if you
want to know what is a script and what isn't. Furthermore, the "-script"
extension doesn't work for this as of today (see your own message a while
back ;-). Keeping it requires discipline that tools don't help enforcing
today (and the extension use itself is very un-Unix-like), so further
"mistakes" /will/ happen.
In any case, this would be for a very specialized, developer-only,
occasional task. I don't see how that warrants a fractured tool namespace
for /all/ users /all/ the time.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
I had the same opinion. The counter-argument people raised when
this topic came up on the list was that it would help grepping
in the source tree.
Grepping for what?
Grepping for strings.
For example, when renaming a binary, the sane way to check that you fixed
all users right now is
grep old-binary-name *.c *.h *-scripts
and you catch all users.
In contrast, "grep *" will catch totally uninteresting patterns like
object files etc.
I personally find that very useful, and I don't see _any_ point to naming
by what _kind_ of interpreter you use. Why would _anybody_ care whether
something is written in perl vs shell? There's no reason to name things by
the interpreter.
Kubys
From: David Kågedal <hidden> Date: 2016-06-15 22:42:05
Linus Torvalds [off-list ref] writes:
On Sun, 4 Sep 2005, Horst von Brand wrote:
quoted
quoted
I had the same opinion. The counter-argument people raised when
this topic came up on the list was that it would help grepping
in the source tree.
Grepping for what?
Grepping for strings.
For example, when renaming a binary, the sane way to check that you fixed
all users right now is
grep old-binary-name *.c *.h *-scripts
and you catch all users.
In contrast, "grep *" will catch totally uninteresting patterns like
object files etc.
I personally find that very useful, and I don't see _any_ point to naming
by what _kind_ of interpreter you use. Why would _anybody_ care whether
something is written in perl vs shell? There's no reason to name things by
the interpreter.
But to the users (like myself), there's no point in naming it by
whether it's a script or a binary. Since, as a user, I couldn't care
less that git-foobar is a shell script, I don't want to pollute the
command name space with "-script" suffixes. Calling the command
git-foobar makes much more sense, and allows us to reimplement the
scripts as binaries, or whatever.
So your argument that it makes it easier for git developers to work
with the source doesn't help the user.
The consequence is maybe that the scripts should be called *-script in
the source, but be installed without the suffix?
--
David Kågedal
But to the users (like myself), there's no point in naming it by
whether it's a script or a binary.
So? There's no downside.
To you, as a user, you never see the "-script" ending anyway. You'd never
type it out, or you're already doing something wrong.
So to users it doesn't matter, and to developers it _does_ matter (and
calling them ".pl" or ".sh" or something would be _bad_), why not please
the developers?
So your argument that it makes it easier for git developers to work
with the source doesn't help the user.
It doesn't _help_ the user, but since it doesn't hurt him either, why the
hell would we even _care_ about the user?
Linus
From: David Kågedal <hidden> Date: 2016-06-15 22:42:05
Linus Torvalds [off-list ref] writes:
On Mon, 5 Sep 2005, David Kågedal wrote:
quoted
But to the users (like myself), there's no point in naming it by
whether it's a script or a binary.
So? There's no downside.
To you, as a user, you never see the "-script" ending anyway. You'd never
type it out, or you're already doing something wrong.
Then I'm doing something wrong. And I'm pretty sure others are
too. If I'm not supposed to see the "-script" ending, then don't
install it in my $PATH.
Until someone (possibly myself) writes some zsh completion code to
handle git sub command, I will continue to hit TAB and see all those
names.
Furthermore, the man page for "git clone" is called
"git-clone-script(1)". And the "-script" suffix appears inside the
documentation in various places. I see it in howtos and log messages.
And the git-merge-one-file-script script is supposed to be used in a
way where I have to supply the long name. Etc.
If the "-script" part is supposed to be hidden from me, why do I keep
seeing it everywhere I turn?
So to users it doesn't matter, and to developers it _does_ matter (and
calling them ".pl" or ".sh" or something would be _bad_), why not please
the developers?
I'm not suggesting we'd call them ".pl" or ".sh".
--
David Kågedal
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:05
On 9/6/05, Linus Torvalds [off-list ref] wrote:
Grepping for strings.
For example, when renaming a binary, the sane way to check that you fixed
all users right now is
grep old-binary-name *.c *.h *-scripts
and you catch all users.
Grep knows how to ignore binary files. Try:
grep -I git-commit *
cheers,
martin
That wasn't the _point_.
The point is, naming things as being "scripts" is useful. Grep is just an
example. Naming things as being ".pl" or ".sh" is _not_ useful.
So with grep you can use -I, but what about doing things like "em *" when
doing global renames (I use micro-emacs - em - as my editor). Again, "em
*-script" actually works.
The point being that if we have naming rules, make them USEFUL. *-script
is useful - it works wonderfully well for "git xxx" (which knows to add
"-script"), and it works wonderfully well for developers.
Linus
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:05
On 9/6/05, Linus Torvalds [off-list ref] wrote:
That wasn't the _point_.
Agreed - sorry I should have qualified my comment.
I agree with having useful extensions for ease of development. And I
agree with the suggestion of installing them with stripped extensions
-- to extend the abstraction.
OTOH...
The point is, naming things as being "scripts" is useful. Grep is just an
example. Naming things as being ".pl" or ".sh" is _not_ useful.
Hrmmm. Not so convinced about that. There are good reasons to
distinguish files with different internal syntax. Perhaps it's your
C-bias but for script maintainers it isn't helpful to deal with
-script prefixes.
If a bash script is rewritten in C, it is a useful and meaningful
change (from a developer perspective) that the file changes name. Both
can live in the tree while the new one matures, running diffs or
pickaxes will show one file created and another removed, instead of a
very meaningless diff. The same applies if it is rewritten in Perl, or
Python.
IOW: Perl programmers are developers too ;-)
cheers,
martin