🚀 go-pugleaf

In article <7214@hydra.Helsinki.FI>, kankkune@cs.Helsinki.FI (Risto Kankkunen) writes:
> In article <2728@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
>>A parameter starting with @ is taken to be a 'response file'. The response
>>file is read in and inserted into the command line replacing the @filename...
>
> I don't see this as the final solution, because it is a purely
> syntactic, command line convention. What if you use sh, csh, ksh or
> some other command interpreter than COMMAND.COM? Those shells may
> already have some special meaning for @-character. Or what if you have
> a program that wants @-character as one of its parameters? 
> 
Quite right, it shouldn't be a "final solution", but it isn't all that bad for
the moment, either. But it must be implemented in the individual programs - the
command interpreter itself shouldn't expand any "@filename" it finds, because
there are going to be programs that actually want a "@" for some good reason.
Any good shell worth its salt should have the ability to force through any
character (like "@") to the program, even though it would like to interprete it
in some special way. I guess the original thoughts behind the discussion
included what "standard" should a programmer try to adopt now. I think
individual programs should look for a variety of possibilities, the environment
"CMDLINE" seems reasonable (and even if you don't like it, you shouldn't use it
for anything else), the "@" in parameters seems good too, but some people like
to use "@" in filenames (see my comments below), and individual programs may
have their own ideas about gathering extra information from environment
variables and/or special configuration files. Ultimately, it looks like DOS
will want to use the special area after the environment. I believe command
interpreters could set this up now, even without waiting for DOS to do it, but
with some large degree of mess (loading a program in "by hand", and all that).
What is important is what goes in on the application program side of things.

Now, the question of "@" in filenames. Personally, I prefer to keep punctuation
out of filenames, mainly because I work in an environment where DOS and UNIX
and VMS have to co-exist, so taking filenames to their limit in one
environment can cause problems if the file ever has to be moved. Some operating
systems treat "@" as special (e.g. in AOS it implies a peripheral device, of
all things, and in many systems it means "the contents of a text file" rather
than the file itself). We shouldn't try to encourage all sorts of junk going
into filenames (i.e. filenames should be *names*, not !@&^$!?!! punctuation!).
However, I realise that these are just my opinions, and it is reasonable to be
able to override such restrictions - but its also reasonable that anyone who
wants to do strange things with filenames should have to go to a little extra
effort in pushing them through the system.

The command shell itself probably does need a method of being told to take the
contents of a file and stuff it into a command line. My favourite method is to
avoid using a single character to do this, for compatibility reasons, but to
use a construct like: DELETE [@filename]  - i.e. both [ and @ are needed, so
few people can complain that they *really need* a filename starting with [@ in
their program. The actual method may change from shell to shell, by it should
generate the input to the program, under whatever o/s, that is appropriate for
the job, e.g. CMDLINE if it has to, or extra parameters after the environment,
or whatever.

> Passing the arguments at the end of the area for environment variables
> would solve these problems: It would not put any character into a
> special role, and thus arbitrary strings could be passed to programs.
> And because the command line would be broken up into arguments, the
> program wouldn't have to parse it (and try to guess what command shell
> the user has to do it right).
> 
But the parsing is going to make assumptions, e.g. some people consider that: 
PRINT file1,file2,file3 file4 has 2 parameters after the "PRINT" (one is the
concatenation of files 1,2 & 3, which would be printed as one file, then file4;
others would expect 4 separate parameters. Some programs treat what others
consider to be a delimiter as special, and need to know it). I still like the
idea of pre-parsing the input, but there could be problems, simply because of
the gigantic lack of standardisation between and within operating systems!
Hopefully, the start of the un-processed command line would still be there, in 
the PSP, but somebody (everybody?) has to work out what you can expect a shell 
to do and not do first, and allow time for program writers to adjust to that. At
the moment, the majority of programs for PC's at least are written under the
assumption that they will be called from COMMAND.COM, not some "foreign" shell.

I imagine it is possible to come up with a small list of what a program can
expect its shell to pass to it, without restricting shell writers too much. It
may involve caveats like "this shell requires such lines to be prefixed by
(some obscure character)" or "that shell will handle such things by default".
Such a set of guidelines might involve suggestions on characters that are good
to put in filenames (consider a teaching environment where one o/s lets you put
anything into a filename at one stage, but prohibits you from deleting or
renaming it at another - its all very well saying that an o/s should let you do
anything, but when a bunch of learners get fouled up because of that [partial]
freedom, it isn't much fun). So I don't think it is too much of a restriction
or infringement of civil liberties to say "don't make filenames with "@" at the
start, unless you (go through some strange Druid ritual) and are prepared to
handle problems down the line".

I realise the information content is dropping a bit as personal opinions take 
over, so feel free to e-mail me with further comments, flames, whatever. In
particular, I'd be interested to here from anyone for whom a "@" (or even "[@"
sequence) at the start of a parameter is essential, and any serious problems
with any of the suggestions so far (or new ideas). 

Mark Aitchison, University of Canterbury, Gnu Zealand.