I wish to do
lua prog.lua arg1 arg2
from the command line
Inside prog.lua, I want to say, for instance
print (arg1, arg2, '\n')
Lua doesn't seem to have argv[1] etc and the methods I've seen for dealing with command line arguments seem to be immature and / or cumbersome. Am I missing something?
You're missing the arg vector, which has the elements you want in arg[1], arg[2], and so on:
% lua -i -- /dev/null one two three
Lua 5.1.3 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> print(arg[2])
two
>
More info in the Lua manual section on Lua standalone (thanks Miles!).
In addition to the arg table, ... contains the arguments (arg[1] and up) used to invoke the script.
% lua -i -- /dev/null one two three
Lua 5.1.3 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> print(...)
one two three
Lua stores arguments in a table. This table is the "arg" table. You can access the passed arguments inside using arg[1], arg[2], ...
arg[0] is the name of the lua program. arg[1] is the first argument passed, arg[2] is the second argument passed and so on...
If you run file.lua in cmd of freeswitch
freeswitch> luarun prog.lua arg1
You can use prog.lua:
#print(argv[1])
And run: $lua prog.lua arg1 (run in script folder)
You can use prong.lua:
#print(arg[1])
For OP and future visitors,
The library of Lua doesn't contain injecting a table 'args' into globals from command line switches. The program built from lua.c does, however, it is near impossible to use. The reason it is impossible to use is that program does NOT like multiple switches.
This is one of the reasons why my REPL/code executor LuaConsole was built. It gives you the table args as well as sends a tuple to the root pcall function (your executing environment is really a top-level pcall with probably an error handler attached). So both args[n] and local a = {...}; a[n] ...; all work properly with as many switches as you want. For example, -e to execute code from cmd line, -l to specify libraries, etc. It supports anything lua51 and up.
If you are having troubles with the program in the library, I highly suggest you check out https://www.github.com/tilkinsc/LuaConsole as it will save you the headache of dealing with a broken-feeling program. There are also other alternatives out there such as for web, fengari.
Hope this helps you!
Related
The question is described on the title, basically I'd like to execute a command line from scheme, let's say 'ls' and obtaining the output. So my questions are:
Is it possible?
How?
Thanks a lot in advance!
By the way I use Guille.
You need one of these system and system*.
Example: (system "ls")
From the documentation: Guile Reference
— Scheme Procedure: system [cmd]
— C Function: scm_system (cmd)
Execute cmd using the operating system's “command processor”. Under Unix this is usually the default shell sh. The value returned is cmd's exit status as returned by waitpid, which can be interpreted using the functions above.
If system is called without arguments, return a boolean indicating whether the command processor is available.
— Scheme Procedure: system* . args
— C Function: scm_system_star (args)
Execute the command indicated by args. The first element must be a string indicating the command to be executed, and the remaining items must be strings representing each of the arguments to that command.
This function returns the exit status of the command as provided by waitpid. This value can be handled with status:exit-val and the related functions.
system* is similar to system, but accepts only one string per-argument, and performs no shell interpretation. The command is executed using fork and execlp. Accordingly this function may be safer than system in situations where shell interpretation is not required.
Example: (system* "echo" "foo" "bar")
I like to call truncate(const char *path, off_t length) (see man 2 truncate) directly from the command line or in shell script.
I guess I could embed a C program and then compile, run, and remove it.
Another short alternative is using perl -e "truncate($file,$length)".
Questions:
Is perl -e "syscall(params...)" the most common pattern to invoke syscalls? How well does it cover other syscalls?
Is there another common way to invoke Linux/BSD syscalls from the shell?
For instance, using a command like syscall "truncate($file,$length)"?
Thank you for all comments and suggestions. I conclude the following answers to my questions:
Some scripting languages, e.g., perl, may provide functions that resemble or wrap some of the useful syscalls, i.e., those that would make sense calling from the shell.
However, there is no 1:1 mapping of scripting APIs and syscalls and no "common pattern" or tool to invoke many different types of syscalls from the shell.
Moreover, a generic solution for a specific problem should not focus on syscalls in the first place, but rather use a generic language or library from the beginning. For instance, for file truncation this may actually be perl, using perl -e "truncate($file,$length)".
I'm running the debugger in noninteractive mode, with the output written to a file. I want to print out each line of my Perl script as it executes, but only lines in the script itself. I don't want to see the library code (File::Basename, Exporter::import, etc.) that the script calls. This seems like the sort of thing that should be easy to do, but the documentation for perldebug only discusses limiting the depth for dumping structures. Is what I want possible, and if so, how?
Note that I'm executing my program as follows:
PERLDB_OPTS="LineInfo=temp.txt NonStop=1 AutoTrace=1 frame=2" perl -dS myprog.pl arg0 arg1
By default, Devel::DumpTrace doesn't step into system modules, and you can exercise fine control over what modules the debugger will step into (it's not easy, but it's possible). Something like
DUMPTRACE_FH=temp.txt perl -d:DumpTrace=quiet myprog.pl
would be similar to what you're apparently trying to do.
Devel::DumpTrace also does a lot more processing on each line -- figuring out variable values and including them in the output -- so it may be overkill and run a lot slower than perl -dS ...
(Crikey, that's now two plugs for Devel::DumpTrace this week!)
Are you talking about not wanting to step through functions outside of your own program? For that, you want to use n instead of s.
From perldebug:
s [expr] Single step. Executes until the beginning of another
statement, descending into subroutine calls. If an
expression is supplied that includes function calls, it too
will be single‐stepped.
n [expr] Next. Executes over subroutine calls, until the beginning
of the next statement. If an expression is supplied that
includes function calls, those functions will be executed
with stops before each statement.
Take an undocumented executable of unknown origin. Trying /?, -h, --help from the command line yields nothing. Is it possible to discover if the executable supports any command line options by looking inside the executable? Possibly reverse engineering? What would be the best way of doing this?
I'm talking about a Windows executable, but would be interested to hear what different approaches would be needed with another OS.
In linux, step one would be run strings your_file which dumps all the strings of printable characters in the file. Any constants chars will thus be shown, including any "usage" instructions.
Next step could be to run ltrace on the file. This shows all function calls the program does. If it includes getopt (or familiar), then it is a sure sign that it is processing input parameters. In fact, you should be able to see exactly what argument the program is expecting since that is the third parameter to the getopt function.
For Windows, you can see this question about decompiling Windows executables. It should be relatively easy to at least discover the options (what they actually do is a different story).
If it's a .NET executable try using Reflector. This will convert the MSIL code into the equivalent C# code which may make it easier to understand. Unfortunately private and local variable names will be lost, as these are not stored in the MSIL but it should still be possible to follow what's going on.
How do I detect what command line arguments where given when a script is run with racket? That is, the equivalent of sys.argv in Python, args[] in Java, etc...
You have these choices (you can look them all up in the docs for more info):
current-command-line-arguments -- a vector holding the command line arguments
You can start a script with the -m flag, which will require the file and look for a provided main function, then apply it on the command-line arguments (as a list of strings)
Or you can require racket/cmdline which provides a macro that can be used to define several flags in a convenient way.