I know that environment variables are stored in the processes memory but what format are command line arguments stored in?
In Linux, command line arguments are pushed on the stack with the count of arguments being on top of the stack. If you write an assembly language program, then you can read the command line arguments by popping them from the stack.
They're just stored with the environment as (more) null-terminated strings. Some software has been known to write to them (among other techniques) to display status information via ps(1).
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")
Suppose you have an interpreter that takes command line arguments including the filenames for a script to be run, and optionally further arguments to be passed to the script. The interpreter then needs to figure out which of the given arguments were intended for its own use and which were intended to be passed to the script.
Is there a widely used convention for separating the former from the latter?
With Bash
-- A -- signals the end of options and disables further option
processing. Any arguments after the -- are treated as file-
names and arguments. An argument of - is equivalent to --.
With CMD :: is often used as a dummy argument to indicate recusrsion for instance. Prefixed on a line, it can be used to turn the line into a comment, giving a handy "programmed-skip" facility
I am using NtQueryInformationProcess() to retrieve the command line of another process (via the RTL_USER_PROCESS_PARAMETERS in the PEB returned by NtQueryInformationProcess()) on Windows 7.
This generally works fine, but when multiple instances of the same executable are started the command line string is the same for all instances: it always is the command line of the first instance that was started. GetCommandLine() returns the correct command line for each process though.
Can someone confirm or falsify this?
What you are probably missing is that each pointer in PEB is only relevant in address space of the PEB's process rather than the process that called NtQueryInformationProcess and retrieved the PEB. You have to use ReadProcessMemory to derference pointers. Otherwise, since processes are likely to be laid out similarly, you end up reading the command line of the NtQueryInformationProcess caller and not that of the PEB's process.
I can confirm that Using NtQueryInformationProcess and ReadProcessMemory for each level of pointer indirection you can get command lines of all processes correctly. See https://stackoverflow.com/a/13408150/1236546 for source code example.
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.