Ian, I was thinking of adding support for somethng like "<@ filename" in the command line as mean simply ready the contents of the file as if it were part of the command line at the point in question and substititute the contents in place of the "<@ filename" construct. Then parse the resulting command line (now much longer) as if it were the original command line (therefore all syntax issues are automatically resolved). I think would only add about 50-100 bytes to the start-up code so that might not be an intolerable over-head. It could also be vectored so that the support could easily be omitted or included as required. I would have to decide if the default was to include or omit the support - although my inclination would be to include it by default so most programs got the facility.
Dave ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 22, 2002 9:38 AM Subject: RE: [ql-users] c68 question > I've not encountered any Unix shells that offer such a syntax, or any way of doing it from a program. I believe the cpio and tar Unix utilities support file-lists as an alternative to specifying the individual filenames on the command line, because the length of command line could easily become very long; but this is implemented by their own code, not the command line parser. > > To implement such a feature, you'd need to agree not only the new command line syntax, but also a standard for the format of an argument list file, i.e comma/space/tab/semicolon separated list or each line = one arg with white space literal? Ideally environment variable substitution should be handled in the file just like on the command line. The startup code could become very large, disproportionately so if tacked onto trivial programs, and wasteful of disk space when included with every program even if they don't need the feature. > But if all this could be built into the EX command in a future version of SMSQ/E, then it would be a different matter entirely... > Just my two pen'orth. :) > > Ian. > > >-----Original Message----- > >From: Dave Walker [mailto:[EMAIL PROTECTED]] > >Sent: 21 April 2002 11:09 > >To: [EMAIL PROTECTED] > >Subject: Re: [ql-users] c68 question > > > > > >There is no standard way to get a file re-directed to be treated as a > >command line in c68. > > > >You can do file level re-direction and then process the input > >as though it > >comes from "stdin". The standard c68 start-up code will > >handle attaching > >the input as stdin, but the processing of this input so that > >it can be an > >alternative to the command line has to be implemented within > >the program > >itself and is not a standard feature of the c68 start-up code. > > > >The main reason that this is not done is simply because there > >is no agreed > >syntax that specifies the parameters for a command line are > >coming from a > >file. It would be relatively trivial to enhance the C68 > >start-up code to > >implement such a feature given an agreement on the syntax for > >recognising > >the command line re-direction to a file for parameters. The > >idea sounds > >like a good one, so if anyone has suggestions on a proposed syntax I am > >happy to consider them for inclusion into the standard c68 > >build. Is there > >any standard for this in the Posix/Unix world as I have not > >come across such > >a feature? What about other OS? > > > >Dave > > > >----- Original Message ----- > >From: "P Witte" <[EMAIL PROTECTED]> > >To: "ql users mailing list" <[EMAIL PROTECTED]> > >Sent: Saturday, April 20, 2002 10:28 PM > >Subject: [ql-users] c68 question > > > > > >> Is there a way to get a c68 program to accept a commandline > >> (or part of a command line) from a file/pipe. > >> > >> I want to achieve something like: > >> > >> EX cprog ; "-options parameters <filelist_file" > >> > >> rather than > >> > >> EX cprog ; "-options parameters file1 file2 .. fileN" > >> > >> Or is all this entirely up to cprog? > >> > >> Per > >> > >> > >> > >> > >> > >> > > > > > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. >
