[plt-dev] renaming programs in the distribution

On Tue, Apr 20, 2010 at 2:37 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Tue, 20 Apr 2010 14:07:02 -0400, Carl Eastlund wrote:
>> On Tue, Apr 20, 2010 at 1:54 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>> > At Tue, 20 Apr 2010 13:25:39 -0400, Carl Eastlund wrote:
>> >> Version 3 is troublesome.  It gives a short name to encourage people
>> >> to run "racket <file>" so they don't have to do long stuff... but then
>> >> punishes them if they use that to build a script and ever have a file
>> >> with a similar name to a command.
>> >
>> > That doesn't sound quite right. With option 3, `racket' would decide on
>> > file versus command syntactically, without consulting the set of
>> > available commands or files. So, changes in available files or commands
>> > do not change the interpretation of a command line.
>>
>> Okay, let's say I write "racket my-favorite-string".  What syntactic
>> decision does "racket" use to pin "my-favorite-string" down as a
>> potential command versus a potential file name?
>
> The absence of ".", "/", and "\" means that it's a command name.
>
>> It still seems to me
>> that any potential command may still be something a user might want to
>> use as a potential file name.
>
> Yes. In that specific case, you'd have to use `racket run
> my-favorite-string' or `racket ./my-favorite-string'.
>
>> > I believe that a script implementor would be punished only if the
>> > script was called from its own directory without using a path prefix
>> > and when "." is in PATH.
>>
>> This sounds like an issue when using racket in #! lines.  That's not
>> the kind of script I meant.  I mean a #!/bin/bash script that calls
>> something like "racket $*" in it to invoke one or more files.  There
>> is trouble if the files coincide with command names, or the syntactic
>> shape of commands, or whatever racket uses to decide something is not
>> a file name.
>
> I see what you mean. Yes, you'd need to write `racket run "$whatever"'
> or `racket -u "$whatever"' if you don't know what shape `"$whatever"'
> will have and you want it to be treated as a file name.
>
>
> Is a script implementer who writes
>
>  racket $*
>
> doing anything sensible at the level of preserving filenames,
> considering the way that $* expands to multiple arguments without
> quoting them? Probably the script implementer needs to write something
> like
>
>  racket -u ${1+"$@"}
>
> Just because bash scripting is fragile and complicated is not a good
> reason to make it more so. Still, it may not be the case to try to make
> nice.

Thanks for clarifying how option 3 works.

In my script example, take the bash quoting stuff as a given.  Anyone
writing in bash needs to know how to quote things.  It's the "-u" flag
that troubles me.  One could claim that anyone calling racket needs to
know about "-u", but "racket <file.rkt>" seems to contradict that.  We
seem to be supporting that precisely so that users do not need to know
about "-u".  Certainly, if we present "racket <file.rkt>" as the most
common way to run files, no matter how often we document "-u" as the
more general case, there will be people who only learn the one and not
the other.

The choice of distinction between filenames and command names (period,
slash, and backslash) is somewhat comforting -- version 3 is not
completely unpredictable, but I'm still skeptical of it and still put
it last.  I had ten spaces between "2 1B" and "3" in my updated vote;
cut that in half or so.

--Carl