How do you run Scheme programs from the terminal in linux(ubuntu)? Also how to accept arguments from the command-line in a Scheme program?
Edit: Im using the DrScheme implementation.
The DrScheme scheme implementation, and the name you use to execute it from the command line, is mzscheme. The documentation for starting a command line script is found here: Unix Scripts (PLT Scheme documentation). Use of the command line args is explained here: Command-line Parsing (PLT Scheme Documentation).
The upshot is that you can use shebang scripts like this:
#! /usr/bin/env mzscheme
#lang scheme/base
(...scheme s-exps...)
or if you want more control over the command line flags for mzscheme, you need to start the script like this:
#! /bin/sh
#|
exec mzscheme -cu "$0" ${1+"$#"}
|#
#lang scheme/base
(...scheme s-exps...)
The function you use to process command line args is command-line. You will find examples of how to use it in the article linked to by the second link.
It is not standardized in the R6RS. There is a recommendation SRFI-22, which some interpreters support. If your interpreter does not support SRFI-22 then it depends on your implementation.
Below is an example from the SRFI. It assumes your interpreter is a binary named scheme-r5rs. Basically it calls a function named main with a single arg that is a list of command line args.
#! /usr/bin/env scheme-r5rs
(define (main arguments)
(for-each display-file (cdr arguments))
0)
(define (display-file filename)
(call-with-input-file filename
(lambda (port)
(let loop ()
(let ((thing (read-char port)))
(if (not (eof-object? thing))
(begin
(write-char thing)
(loop))))))))
This solution works for me
#! /usr/bin/env guile
!#
(display "hello")
(newline)
Also how to accept arguments from the
command-line in a Scheme program?
The R6RS library defines a function called command-line which returns the list of the arguments (the first one being the name of the program). Not all implementations of Scheme implement R6RS though; your implementation might have some other function for this.
How do you run Scheme programs from
the terminal in linux(ubuntu)?
It depends on which implementation of Scheme you're using.
Related
Tying a script to a specific interpreter via a so-called shebang line is a well-known practice on POSIX operating systems. For example, if the following script is executed (given sufficient file-system permissions), the operating system will launch the /bin/sh interpreter with the file name of the script as its first argument. Subsequently, the shell will execute the commands in the script skipping over the shebang line which it will treat as a comment.
#! /bin/sh
date -R
echo hello world
Possible output:
Sat, 01 Apr 2017 12:34:56 +0100
hello world
I used to believe that the interpreter (/bin/sh in this example) must be a native executable and cannot be a script itself that, in turn, would require yet another interpreter to be launched.
However, I went ahead and tried the following experiment nonetheless.
Using the following dumb shell saved as /tmp/interpreter.py, …
#! /usr/bin/python3
import sys
import subprocess
for script in sys.argv[1:]:
with open(script) as istr:
status = any(
map(
subprocess.call,
map(
str.split,
filter(
lambda s : s and not s.startswith('#'),
map(str.strip, istr)
)
)
)
)
if status:
sys.exit(status)
… and the following script saved as /tmp/script.xyz,
#! /tmp/interpreter.py
date -R
echo hello world
… I was able (after making both files executable), to execute script.xyz.
5gon12eder:/tmp> ls -l
total 8
-rwxr-x--- 1 5gon12eder 5gon12eder 493 Jun 19 01:01 interpreter.py
-rwxr-x--- 1 5gon12eder 5gon12eder 70 Jun 19 01:02 script.xyz
5gon12eder:/tmp> ./script.xyz
Mon, 19 Jun 2017 01:07:19 +0200
hello world
This surprised me. I was even able to launch scrip.xyz via another script.
So, what I am asking is this:
Is the behavior observed by my experiment portable?
Was the experiment even conducted correctly or are there situations where this doesn't work? How about different (Unix-like) operating systems?
If this is supposed to work, is it true that there is no observable difference between a native executable and an interpreted script as far as invocation is concerned?
New executables in Unix-like operating systems are started by the system call execve(2). The man page for execve includes:
Interpreter scripts
An interpreter script is a text file that has execute
permission enabled and whose first line is of the form:
#! interpreter [optional-arg]
The interpreter must be a valid pathname for an executable which
is not itself a script. If the filename argument of execve()
specifies an interpreter script, then interpreter will be invoked
with the following arguments:
interpreter [optional-arg] filename arg...
where arg... is the series of words pointed to by the argv
argument of execve().
For portable use, optional-arg should either be absent, or be
specified as a single word (i.e., it should not contain white
space); see NOTES below.
So within those contraints (Unix-like, optional-arg at most one word), yes, shebang scripts are portable. Read the man page for more details, including other differences in invocation between binary executables and scripts.
See boldfaced text below:
This mechanism allows scripts to be used in virtually any context
normal compiled programs can be, including as full system programs,
and even as interpreters of other scripts. As a caveat, though, some
early versions of kernel support limited the length of the interpreter
directive to roughly 32 characters (just 16 in its first
implementation), would fail to split the interpreter name from any
parameters in the directive, or had other quirks. Additionally, some
modern systems allow the entire mechanism to be constrained or
disabled for security purposes (for example, set-user-id support has
been disabled for scripts on many systems). -- WP
And this output from COLUMNS=75 man execve | grep -nA 23 "
Interpreter scripts" | head -39 on a Ubuntu 17.04 box,
particularly lines #186-#189 which tells us what works on Linux, (i.e. scripts can be interpreters, up to four levels deep):
166: Interpreter scripts
167- An interpreter script is a text file that has execute permission
168- enabled and whose first line is of the form:
169-
170- #! interpreter [optional-arg]
171-
172- The interpreter must be a valid pathname for an executable file.
173- If the filename argument of execve() specifies an interpreter
174- script, then interpreter will be invoked with the following argu‐
175- ments:
176-
177- interpreter [optional-arg] filename arg...
178-
179- where arg... is the series of words pointed to by the argv argu‐
180- ment of execve(), starting at argv[1].
181-
182- For portable use, optional-arg should either be absent, or be
183- specified as a single word (i.e., it should not contain white
184- space); see NOTES below.
185-
186- Since Linux 2.6.28, the kernel permits the interpreter of a script
187- to itself be a script. This permission is recursive, up to a
188- limit of four recursions, so that the interpreter may be a script
189- which is interpreted by a script, and so on.
--
343: Interpreter scripts
344- A maximum line length of 127 characters is allowed for the first
345- line in an interpreter scripts.
346-
347- The semantics of the optional-arg argument of an interpreter
348- script vary across implementations. On Linux, the entire string
349- following the interpreter name is passed as a single argument to
350- the interpreter, and this string can include white space. How‐
351- ever, behavior differs on some other systems. Some systems use
352- the first white space to terminate optional-arg. On some systems,
353- an interpreter script can have multiple arguments, and white spa‐
354- ces in optional-arg are used to delimit the arguments.
355-
356- Linux ignores the set-user-ID and set-group-ID bits on scripts.
From Solaris 11 exec(2) man page:
An interpreter file begins with a line of the form
#! pathname [arg]
where pathname is the path of the interpreter, and arg is an
optional argument. When an interpreter file is executed, the
system invokes the specified interpreter. The pathname
specified in the interpreter file is passed as arg0 to the
interpreter. If arg was specified in the interpreter file,
it is passed as arg1 to the interpreter. The remaining
arguments to the interpreter are arg0 through argn of the
originally exec'd file. The interpreter named by pathname
must not be an interpreter file.
As stated by the last statement, chaining interpreters is not supported at all in Solaris, trying to do that will result in the last non-interpreted interpreter (such as /usr/bin/python3) to interpret the first script (such as /tmp/script.xyz, the final command line would become /usr/bin/python3 /tmp/script.xyz), without chaining.
So doing script interpreter chaining is not portable at all.
I wrote hook for command line:
# Transforms command 'ls?' to 'man ls'
function question_to_man() {
if [[ $2 =~ '^\w+\?$' ]]; then
man ${2[0,-2]}
fi
}
autoload -Uz add-zsh-hook
add-zsh-hook preexec question_to_man
But when I do:
> ls?
After exiting from man I get:
> zsh: no matches found: ls?
How can I get rid of from message about wrong command?
? is special to zsh and is the wildcard for a single character. That means that if you type ls? zsh tries find matching file names in the current directory (any three letter name starting with "ls").
There are two ways to work around that:
You can make "?" "unspecial" by quoting it: ls\?, 'ls?' or "ls?".
You make zsh handle the cases where it does not match better:
The default behaviour if no match can be found is to print an error. This can be changed by disabling the NOMATCH option (also NULL_GLOB must not be set):
setopt NO_NOMATCH
setopt NO_NULL_GLOB
This will leave the word untouched, if there is no matching file.
Caution: In the (maybe unlikely) case that there is a file with a matching name, zsh will try to execute a command with the name of the first matching file. That is if there is a file named "lsx", then ls? will be replaced by lsx and zsh will try to run it. This may or may not fail, but will most likely not be the desired effect.
Both methods have their pro and cons. 1. is probably not exactly what you are looking for and 2. does not work every time as well as changes your shells behaviour.
Also (as #chepner noted in his comment) preexec runs additionally to not instead of a command. That means you may get the help for ls but zsh will still try to run ls? or even lsx (or another matching name).
To avoid that, I would suggest defining a command_not_found_handler function instead of preexec. From the zsh manual:
If no external command is found but a function command_not_found_handler exists the shell executes this function with all command line arguments. The function should return status zero if it successfully handled the command, or non-zero status if it failed. In the latter case the standard handling is applied: ‘command not found’ is printed to standard error and the shell exits with status 127. Note that the handler is executed in a subshell forked to execute an external command, hence changes to directories, shell parameters, etc. have no effect on the main shell.
So this should do the trick:
command_not_found_handler () {
if [[ $1 =~ '\?$' ]]; then
man ${1%\?}
return 0
else
return 1
fi
}
If you have a lot of matching file names but seldomly misstype commands (the usual reason for "Command not found" errors) you might want to consider using this instead:
command_not_found_handler () {
man ${1%?}
}
This does not check for "?" at the end, but just cuts away any last character (note the missing "\" in ${1%?}) and tries to run man on the rest. So even if a file name matches, man will be run unless there is indeed a command with the same name as the matched file.
Note: This will interfere with other tools using command_not_found_handler for example the command-not-found tool from Ubuntu (if enabled for zsh).
That all being said, zsh has a widget called run-help which can be bound to a key (in Emacs mode it is by default bound to Alt+H) and than runs man for the current command.
The main advantages of using run-help over the above are:
You can call it any time while typing a longer command, as long as the command name is complete.
After you leave the manpage, the command is still there unchanged, so you can continue writing on it.
You can even bind it to Alt+? to make it more similar: bindkey '^[?' run-help
Executing the script below on osx via emacs, didn't work, I got a permission denied message, the answer to this question solved that problem: https://stackoverflow.com/a/12276562/912475
Tldr: How can I set up a system to automatically pass the word under the cursor in emacs directly to my shell script as a variable and then run that script?
I've created a somewhat rudimentary system for "linking" to folders from plain text files in a robust way. It uses a timestamp that's generated by a script and then set as the "value" of the clipboard. From the clipboard, the timestamp is then pasted into a txt with related notes and into the name field of a folder.
To find the folders when reading the txt I use an emacs function with a keybinding that makes it possible to copy the timestamp (as a word, it's all numbers) to the clipboard and search for it in spotlight (on osx). What I'd like to do instead is to automatically launch a shell script that searches for a directory whose name ends with that string and then opens it. I already have a script that does something like that, but I don't really know how to tie the elisp function and shell script together. I'd greatly appreciate a solution that works on either osx and linux (I use both). It will probably be easy to "port" a solution that works on either one for use with the other.
This is the emacs function for copying a word under the cursor:
;;; function for copying a word under the cursor http://www.emacswiki.org/emacs/CopyWithoutSelection
(global-set-key (kbd "C-c o") (quote copy-word))
(defun copy-word (&optional arg)
"Copy words at point into kill-ring"
(interactive "P")
(copy-thing 'backward-word 'forward-word arg)
;;(paste-to-mark arg)
)
This is the script to find and open the directory whose name ends with the timestamp:
#!/bin/bash
PATH=/opt/local/bin:/opt/local/sbin:$PATH #need this to make the gnu coreutils work on osx
file_number="20130812193913"
path_to_open=$(gfind ~/x/ | grep -e $file_number$) # $ means the end of the line, makes it possible to search for directories without finding their content
open "${path_to_open}"
An edited version of the script that accepts arguments from the commandline like this:
me$ sh script_path.sh 20130812193913
The script:
#!/bin/bash
PATH=/opt/local/bin:/opt/local/sbin:$PATH #need this to make the gnu coreutils work on osx
file_number=$1
echo $file_number
path_to_open=$(gfind ~/x/ | grep -e $file_number$) # $ means the end of the line, makes it possible to search for directories without finding their content
open "${path_to_open}"
See: http://www.bashguru.com/2009/11/how-to-pass-arguments-to-shell-script.html
You could try something like this:
(defvar script-name "/foo/bar/my-script")
(defun call-my-script-with-word ()
(interactive)
(shell-command
(concat script-name
" "
(thing-at-point 'word))))
(global-set-key (kbd "C-c o") 'call-my-script-with-word)
I found the answer to this question while writing it, so I've broadened it a little. I wanted to access the --servername argument, in order to create dynamic settings in my .vimrc file.
Through vim's help, I found the v:servername variable, and my script is working. However, now I'm curious if it's possible to access any arbitrary command-line argument. For example, if I wanted to know if vim was in Lisp mode (-l) or Debugging mode (-D), how would I do it? There seems to be no corresponding v: variable for them.
Here are the variables I found by autocompleting :help v:<Tab>
Is there a general way to access command-line arguments from vimscript?
Strangely, I think the answer may be "No, there is no direct way to access startup options specified on the command line".
The :args command and argv() can be used to access the filename(s) specified on startup, but that's not what you want.
I see on Vim's forums that someone offered this solution to get the startup command line on Linux:
:exe '!tr "\0" " " </proc/' . getpid() . '/cmdline'
I assume there's analogous command on Windows. . . .
You can look over that forum thread here:
http://groups.google.com/group/vim_use/browse_thread/thread/43773f27cdc10265/ad17ae8180c0fb6e?show_docid=ad17ae8180c0fb6e
My googling indicates that this feature has been proposed but never implemented. However I did come up with a bit of a kludge that nevertheless works:
:echo split( system( "ps -o command= -p " . getpid() ) )
# => [ 'vim', ... arguments ... ]
(Tested on OS X Lion.)
The getpid() function gets Vim's PID, then we call ps externally with options to return nothing but the "command" value for process, then use split() to split the command into a list.
How and who determines what executes when a Bash-like script is executed as a binary without a shebang?
I guess that running a normal script with shebang is handled with binfmt_script Linux module, which checks a shebang, parses command line and runs designated script interpreter.
But what happens when someone runs a script without a shebang? I've tested the direct execv approach and found out that there's no kernel magic in there - i.e. a file like that:
$ cat target-script
echo Hello
echo "bash: $BASH_VERSION"
echo "zsh: $ZSH_VERSION"
Running compiled C program that does just an execv call yields:
$ cat test-runner.c
void main() {
if (execv("./target-script", 0) == -1)
perror();
}
$ ./test-runner
./target-script: Exec format error
However, if I do the same thing from another shell script, it runs the target script using the same shell interpreter as the original one:
$ cat test-runner.bash
#!/bin/bash
./target-script
$ ./test-runner.bash
Hello
bash: 4.1.0(1)-release
zsh:
If I do the same trick with other shells (for example, Debian's default sh - /bin/dash), it also works:
$ cat test-runner.dash
#!/bin/dash
./target-script
$ ./test-runner.dash
Hello
bash:
zsh:
Mysteriously, it doesn't quite work as expected with zsh and doesn't follow the general scheme. Looks like zsh executed /bin/sh on such files after all:
greycat#burrow-debian ~/z/test-runner $ cat test-runner.zsh
#!/bin/zsh
echo ZSH_VERSION=$ZSH_VERSION
./target-script
greycat#burrow-debian ~/z/test-runner $ ./test-runner.zsh
ZSH_VERSION=4.3.10
Hello
bash:
zsh:
Note that ZSH_VERSION in parent script worked, while ZSH_VERSION in child didn't!
How does a shell (Bash, dash) determines what gets executed when there's no shebang? I've tried to dig up that place in Bash/dash sources, but, alas, looks like I'm kind of lost in there. Can anyone shed some light on the magic that determines whether the target file without shebang should be executed as script or as a binary in Bash/dash? Or may be there is some sort of interaction with kernel / libc and then I'd welcome explanations on how does it work in Linux and FreeBSD kernels / libcs?
Since this happens in dash and dash is simpler, I looked there first.
Seems like exec.c is the place to look, and the relevant functionis are tryexec, which is called from shellexec which is called whenever the shell things a command needs to be executed. And (a simplified version of) the tryexec function is as follows:
STATIC void
tryexec(char *cmd, char **argv, char **envp)
{
char *const path_bshell = _PATH_BSHELL;
repeat:
execve(cmd, argv, envp);
if (cmd != path_bshell && errno == ENOEXEC) {
*argv-- = cmd;
*argv = cmd = path_bshell;
goto repeat;
}
}
So, it simply always replaces the command to execute with the path to itself (_PATH_BSHELL defaults to "/bin/sh") if ENOEXEC occurs. There's really no magic here.
I find that FreeBSD exhibits identical behavior in bash and in its own sh.
The way bash handles this is similar but much more complicated. If you want to look in to it further I recommend reading bash's execute_command.c and looking specifically at execute_shell_script and then shell_execve. The comments are quite descriptive.
(Looks like Sorpigal has covered it but I've already typed this up and it may be of interest.)
According to Section 3.16 of the Unix FAQ, the shell first looks at the magic number (first two bytes of the file). Some numbers indicate a binary executable; #! indicates that the rest of the line should be interpreted as a shebang. Otherwise, the shell tries to run it as a shell script.
Additionally, it seems that csh looks at the first byte, and if it's #, it'll try to run it as a csh script.