Command Line Behavior

Q&A's, tips, howto's
Locked
johnd
Posts: 18
Joined: Mon May 09, 2005 7:54 pm
Location: San Francisco, CA

Command Line Behavior

Post by johnd »

According to the manual, newLISP will attempt to load files listed on the command line. Is there any way to control this behavior with a flag? I would like to prevent it.

I am sure it is often helpful to have this convenience, but when you want to pass a string as an argument that happens to be the name of a file in the directory it can pose a problem.

For example:

--
Moonrise:Documents jd$
Moonrise:Documents jd$ newlisp list_categories.php

ERR: invalid function : (Admin)
Moonrise:Documents jd$
--

This file is not executable from the command line. Even if one sets the permissions to allow it to be executable it will generate errors.

The other issue here is that this command line behavior is inconsistent. Consider this file:
--
Moonrise:Documents jd$ cat john
#!/bin/sh
echo "johnjohnjohn"

Moonrise:Documents jd$
--

Simple enough. Echo the string to the terminal. This executable file name is treated as a string by newLISP but not executed.

--
Moonrise:Documents jd$ newlisp "john"
newLISP v.9.4.3 on OSX IPv4 UTF-8, execute 'newlisp -h' for more info.

> (main-args)
("newlisp" "john")
>
--

It seems to me that what newLISP considers "a file on the command line" should depend more on a flag setting or on the format of the argument (e.g. "file://..." or something similar) than the contingent contents of the directory.

Thanks,

John[/i]

tom
Posts: 168
Joined: Wed Jul 14, 2004 10:32 pm

Re: Command Line Behavior

Post by tom »

Simple enough. Echo the string to the terminal. This executable file name is treated as a string by newLISP but not executed.
why should newlisp execute a bash shell script?

newlisp -e "(! {./john.sh})"

produces the expected output.

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Post by Lutz »

When invoking a script the first argument is always the name of the script. The script then is processing further arguments before exiting:

Code: Select all

~> cat test
#!/usr/bin/newlisp

(println "main-args:" (main-args) )

(exit)

~> ./test test test
main-args:("/usr/bin/newlisp" "./test" "test" "test")
~> newlisp test test test
main-args:("newlisp" "test" "test" "test")
~> 
"~>" is my shell prompt

Why would anybody invoke newLISP interactively with the first argument not beeing a script?

when you do this:

Code: Select all

~> cat john
#!/bin/sh 
echo "johnjohnjohn" 

~> newlisp john
newLISP v.9.4.5 on OSX IPv4 UTF-8, execute 'newlisp -h' for more info.

> (find 'echo (symbols))
125
> 
newLISP is actually evaluating the contents of the file: john. It will take the first line as a comment and parse the second line as a symbol and a string constant.

johnd
Posts: 18
Joined: Mon May 09, 2005 7:54 pm
Location: San Francisco, CA

Post by johnd »

I should clarify.

The purpose of my shell script example was to argue that an inconsistency exists in the way newlisp evaluates command line arguments. I believed it treated my shell script differently. Lutz demonstrated that was not the case. Hence no inconsistency. Thank you for that clarification.

I don't normally run shell scripts via newLISP. :-)

Lutz asks, "Why would anybody invoke newLISP interactively with the first argument not being a script?"

This is the core of what I want to do. Suppose I just want to send some strings as arguments into newLISP from the command line. The most natural way to do that is as follows:

% newlisp <str1> <str2> <str3>

Now they can be referenced via main-args. Does it really make sense to automatically evaluate them if they happen to be the names of files in the same directory? I say no. Lutz says yes.

It is not merely when running newLISP by itself, however. In my original example I had a program that took arguments.

Thanks,

John

Locked