I have a code, and the error keeps saying usage: ./a.out <integer value>. I looked online for two days to see how to fix it, but I could not find any concrete answers. If someone could tell me what it means, and how I can fix it, that would be wonderful.
It means that when you run your program you will have run it in the command line with an argument:
./ program_name(a.out) integer_value
^^^^^^^^ ^^^^^^
program argument
Where program_name is the name you gave your program when you compiled it, if you do not provide one it's default name will be a.out for linux based systems and a.exe for Windows.
integer_value is an argument you must use, otherwise the condition if(argc != 2) will evaluate to true and the program will exit showing you that message, which is part of the program.
argc is part of the main function's arguments and it represents number of arguments, including the program name, you use when executing the program.
argv is also part of the main function's arguments and is an array of strings in which argv[0] is the program name, argv[1] is the actual argument (if you have more arguments it continues, argv[2], etc.).
To answer your question, the program is fine, it doesn't need fixing, it just needs to be correctly executed. Open a command window/terminal, navigate to the directory where the executable is located an execute it as explained.
BTW, the code should be posted as text, not images.
You can learn more about command line arguments in What does int argc, char *argv[] mean?
Related
I've an application which needs to call a specific program 'mips64-unknown-linux-gcc' for linking all objects from a script with all required args for linking.
I am writing an exec function to call the compiler passed by script along with it's args. For this I wrote the code:
//prog.c : gcc prog.c -o prog
int main(int argc, char *argv[]) {
execvp("mips64-unknown-linux-gcc",argv);
}
This works, but the mips64-unknown-linux-gcc and argv are variables from script input.
I need execv first argument to be a variable which is compiler to be invoked. I can somehow (maybe) retrieve it by getenv(”CC”) but due to other dependencies my requirement is that exec shall accept the compiler and args at runtime (something like below). Is there any way I can do this?
./prog mips64-unknown-linux-gcc --sysroot=<<...>> -O3 -Wl -L <<...>> -L <<...>> -I <<...>> -L <<...>> abcd.o a1.o b2.o -o prog
I described my problem at my best. Please ask if anything is not clear.
From your example command line it seems that you want to take the first argument from command line as your command to execute and everything else should be passed to that command.
That is basically the same command line execpt for the first argument.
This makes things rather easy.
Looking at argv you will find these string:
char *argv[] = {"proc","mips64-unkown-linux-gcc", "--sysroot=<<...>>", ..., "-o", "prog", NULL};`
You can use that and call your command:
execvp(argv[1], argv+1);
Of course you should check whether you have at least one argument.
If you want do filter some options and handle in your own program instead of blindly passing it to execvp you must rebuild your own array of arguments where you do not include those options.
How is it possible that Cygwin seemingly manages to bypass the MS C Runtime library enabling a C program to get its argv like a Linux machine would?
I'll explain what I mean.
On Windows I understand that a C program has the choice of calling GetCommandLine() or of using argv.
And I understand that a windows implementation of C compiler would make C programs implicitly call the MS C Runtime Library, which will take the command line (perhaps outputted by GetCommandLine()), that isn't separated into arguments, and it'll take that as input and parse it, putting it into argv. This link mentions about that https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170
And from what I understand, on Linux, what's written after the command at the command line, goes straight from the shell to argv. No external library doing the parsing. The shell calls a POSIX function called execv and figures out what the arguments are and passes them to execv which passes them to the program's argv.
I use these programs for some tests
C:\blah>type w.c
#include <stdio.h>
#include <windows.h>
int main(int argc, char *argv[]) {
printf(GetCommandLine());
return 0;
}
C:\blah>w.exe "asdf" erw
w.exe "asdf" erw
C:\blah>
C:\blah>type w2.c
#include <stdio.h>
int main(int argc, char *argv[]) {
int i = 0;
while (argv[i]) {
printf("argv[%d] = %s\n", i, argv[i]);
i++;
}
return 0;
}
C:\blah>w2 abc "def"
argv[0] = w2
argv[1] = abc
argv[2] = def
C:\blah>
And w2.c can be run from linux too
root#ubuntu:~# ./w2 abc "def"
argv[0] = ./w2
argv[1] = abc
argv[2] = def
root#ubuntu:~#
I notice that there are some cases where the MS C Runtime gives a different parsing, to Linux. (Linux of course wouldn't be using the MS C Runtime)
For example, this link https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170 mentions this command line input a\\\b d"e f"g h and expected outputs.
C:\blah>w2 a\\\b d"e f"g h
argv[0] = w2
argv[1] = a\\\b
argv[2] = de fg
argv[3] = h
C:\blah>
Whereas on Linux, one gets
root#ubuntu:~# ./w2 a\\\b d"e f"g h
argv[0] = ./w2
argv[1] = a\b
argv[2] = de fg
argv[3] = h
So now the interesting test was, what would Cygwin do
user#comp /cygdrive/c/blah
$ ./w2 a\\\b d"e f"g h
argv[0] = C:\blah\w2.exe
argv[1] = a\b
argv[2] = de fg
argv[3] = h
Cygwin manages to get the result that a linux machine would give.
But it's running an EXE file that was compiled on Windows and that i'd have thought must be using the MS C Runtime library. And when running the EXE file from CMD outside cygwin, then it does look like it's using the MS C Runtime Library. So how is Cygwin seemingly managing to bypass that to lead the program to give the result that a linux machine would give.
How is this possible?! What is going on?!
I conversed with somebody that knows about cygwin.. They said that cygwin can detect whether an executable is a windows executable, or a cygwin executable. And the ldd command can do so. And a cygwin executable will be linked to cygwin1.dll. A program like sysinternals process explorer can show what DLLs are linked to a running process e.g. it shows that bash.exe is linked to cygwin1.dll. But the ldd command is more useful here as it shows also for commands that aren't kept open. $ ldd /bin/bash.exe showed some NT related DLLs, but also cygwin1.dll. Whereas $ldd ./w.exe showed just NT related Dlls, no cygwin1.dll.
And they said that this file winsup/cygwin/winf.cc is very relevant to that. I have it on my system https://gist.github.com/gartha1/4a2871b7f22ef85b5c8c0b08674b6f57 I see it has stuff about argv
Some comments and C guys I conversed with have indicated to me, and from my understanding of what they said, that Linux has some compiler specific C runtime libraries. And when people say C runtime libraries, they tend to mean to include also POSIX functions like execv, that is technically not part of the C standard, but part of the POSIX standard. And the runtime libraries apply before main starts and after end finishes.
I was looking at it from the point of view is, this is the command line, i've typed, and what is then sent to argv, and how. But another perspective is, looking at what's sent to argv, and taking a step back and what's the value at GetCommandLine() that'd produce that. And also I think, looking at the command line typed, and seeing what it sends or would send to GetCommandLine().
The MS C Runtime, starts with GetCommandLine() then calls GetCommandLineToArgs() https://learn.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-getcommandlinea "GetCommandLine as an alias which automatically selects the ANSI or Unicode version of this function" and "To convert the command line to an argv style array of strings, pass the result from GetCommandLineA to CommandLineToArgW." What is the difference between the `A` and `W` functions in the Win32 API? "The A functions use Ansi (not ASCII) strings as input and output, and the W functions use Unicode string instead .."
So, what MS C Runtime sees when it does GetCommandLine() is very significant. And I think Cygwin's linux shell e.g. bash , does its parsing.. which is described by info bash and includes "word splitting"(separating arguments), and quote removal.
calc.exe is useful because it stays open so I can look at the command line with WMIC. That's clearer than using w.exe(from cmd), to determine what the command line is.
To use some simple examples with calc.exe trying calling it with command line of
calc "abc"
calc a\a
In the case of calc "abc", what gets into argv in Cygwin and plain cmd is the same. And what gets seen by GetCommandLine() won't really need any adjustment, though cygwin sanitises what it makes available to GetCommandLine() a bit.
Looking with CMD, we see
C:\>w calc abc
w calc abc
C:\>w calc "abc"
w calc "abc"
C:\>w2 calc abc
argv[0] = w2
argv[1] = calc
argv[2] = abc
C:\>w2 calc "abc"
argv[0] = w2
argv[1] = calc
argv[2] = abc
So a value from GetCommandLine() of calc "abc" or calc abc are equivalent
I'm using wmiccalc.exe which runs the line wmic process where caption="calc.exe" get commandline | calc "abc"
C:\>calc "abc" <ENTER>
C:\>wmiccalc.bat<ENTER>
calc "abc"
Now see what happens if I run calc from cygwin, what the command line is
$ calc "abc" &
$ ./wmiccalc.bat
C:\Windows\System32\calc.exe abc
It is using a slightly sanitised command line that won't change anything in terms of what is sent to argv(what it gives the runtime to send to argv), relative to what the pure cmd call of calc.exe will end up (via the runtime), sending through to argv.
In both cases it'd be the MS C Runtime. That gets run.
What Cygwin did was it took the "abc" and said, well, bash will want abc in argv, so it constructed a command line that (when sent through the MS C Runtime), would/will send abc to argv.
Now let's look at this example
2. calc a\a
This is slightly different to the first example. 'cos not just what is sent (via the MS C runtime), to argv in the cygwin case and the cmd case are different..
What is produced by the MS C Runtime, is different.
Cygwin sends what it wants to send, to produce the output that bash wants produced.
C:\>calc a\a
C:\>wmiccalc.bat
calc a\a
From Windows, that's the command line
And from that command line, The MS C Runtime will send the following to argv
>w2 a\a
argv[0] = w2
argv[1] = a\a
If though an executable in linux gets a command line like a\a , it treats the backslash as an escape character.. so it wouldn't have a\a going to an argv.
$ echo a\a
aa
So if I do
$ calc a\a &
$ ./wmiccalc.bat
C:\Windows\System32\calc.exe aa
So cygwin will use a very different command line.. a command line of aa not a\a
$ ./w2 a\a
argv[0] = ......\w2.exe
argv[1] = aa
And that makes sense, because if we look at CMD, a command line a\a gets what we'd want if having that command line on windows.
>w2 a\a
argv[0] = w2
argv[1] = a\a
>
Whereas a command line of aa i.e. the MS C Runtime seeing a GetCommandLine() result of aa, gets what we'd want in argv if running it from linux or bash
>w2 aa
argv[0] = w2
argv[1] = aa
>
So, if you run the executable on windows plain CMD not cygwin, you get what it should show for Windows.
And if you run the executable from Cygwin, cygwin's shell e.g. bash shell, parses it constructs the windows call to the program so that it gives MS C Runtime the command line so that Ms C Runtime will put the right things into argv to give what a linux machine would show. So it's not bypassing MS C Runtime. It's using it cleverly. It's saying "Having parsed the output given to me by the linux shell e.g. bash, I know what argv values I want, so i'll put together a command line that takes into account how MS C Runtime parses things, so as to get the argv values I want"
By the way
One of the comments corrects one of the things I wrote in my question.. I wrote
And from what I understand, on Linux, what's written after the command
at the command line, goes straight from the shell to argv. No external
library doing the parsing. The shell calls a POSIX function called
execv and figures out what the arguments are and passes them to execv
which passes them to the program's argv.
But actually, there's a C Runtime used by compilers on linux.. The POSIX function execv would be considered to be part of that. If somebody didn't want to call it C Runtime, they could call it C/POSIX runtime.
Also some comments to the question helped correct some misconceptions in areas of lack of clarity in the question e.g.
To the question of "And am I correct in thinking that the shell passes the command line or some function of it, to the Runtime, which puts the command line into argv?"
this comment explained how what the shell wants the arguments to be, will eventually get to main(And thus argv). Never going straight there, and not even from the shell straight to the runtime.. From shell to OS to runtime.
"
#barlop: The shell passes the command line to the operating system, probably by calling CreateProcess (one of arguments of that function is the command line). The operating sytem then creates a new process, which causes the C run-time library to take control. The run-time library will probably call the Windows API function GetCommandLine and will use the returned information to set argc and argv, before it calls main. –
Andreas Wenzel"
Consider that the shell (bash?) in Cygwin does its own parsing of the command line before any Windows function is called to launch the application. Since this shell is more compatible to a Linux shell, I'd expect the same outcome, in contrast to the parsing of CMD. –
the busybee
"
Anyhow, I think this addresses what is happening.. How the command line typed into cygwin is transformed to a string seen by GetCommandLine() and gets the result using the MS C Runtime library.
I used two simple examples but they would explain it for the case given in the question too.
I have a shell script which has to take arguments from the command line and pass it to a function in C. I tried to search but didn't find understandable solutions. Kindly help me out.
Should the arguments be passed via an option as a command in the shell script?
I have a main function like this:
int main(int argc, char *argv[])
{
if(argc>1)
{
if(!strcmp(argv[1], "ABC"))
{
}
else if(!strcmp(argv[1], "XYZ"))
{
}
}
}
How to pass the parameters ABC/XYZ from the command line through a shell script which in turn uses a makefile to compile the code?
You cannot meaningfully compare strings with == which is a pointer equality test. You could use strcmp as something like argc>1 && !strcmp(argv[1], "XYZ"). The arguments of main have certain properties, see here.
BTW, main's argc is at least 1. So your test argc==0 is never true. Generally argv[0] is the program name.
However, if you use GNU glibc (e.g. on Linux), it provides several ways for parsing program arguments.
There are conventions and habits regarding program arguments, and you'll better follow them. POSIX specifies getopt(3), but on GNU systems, getopt_long is even more handy.
Be also aware that globbing is done by the shell on Unix-like systems. See glob(7).
(On Windows, things are different, and the command line might be parsed by some startup routine à la crt0)
In practice, you'll better use some system functions for parsing program arguments. Some libraries provide a way for that, e.g. GTK has gtk_init_with_args. Otherwise, if you have it, use getopt_long ...
Look also, for inspiration, into the source code of some free software program. You'll find many of them on github or elsewhere.
How to pass the parameters ABC/XYZ from the command line through a shell script
If you compile your C++ program into an executable, e.g. /some/path/to/yourexecutable, you just have to run a command like
/some/path/to/yourexecutable ABC
and if the directory /some/path/to/ containing yourexecutable is in your PATH variable, you can simply run yourexecutable ABC. How to set that PATH variable (which you can query using echo $PATH in your Unix shell) is a different question (you could edit some shell startup file, perhaps your $HOME/.bashrc, with a source code editor such as GNU emacs, vim, gedit, etc...; you could run some export PATH=.... command with an appropriate, colon-separated, sequence of directories).
which in turn uses a makefile to compile the code?
Then you should look into that Makefile and you'll know what is the executable file.
You are using and coding on/for Linux, so you should read something about Linux programming (e.g. ALP or something newer; see also intro(2) & syscalls(2)...) and you need to understand more about operating systems (so read Operating Systems: Three Easy Pieces).
See following simple example:
$ cat foo.c
#include <stdio.h>
int main(int argc, char ** argv)
{
int i;
for (i = 0; i < argc; ++i) {
printf("[%d] %s\n", i, argv[i]);
}
return 0;
}
$ gcc foo.c
$ ./a.out foo bar
[0] ./a.out
[1] foo
[2] bar
$
This question already has an answer here:
Pass File As Command Line Argument
(1 answer)
Closed 8 years ago.
So, I can make my program run and all, but if I'm given
$ ./a.out -f Text.txt
I'm just not sure how to get the program to make the connection that -f indicates a file. What is the logic for doing this?
The main function has signature int main(int argc, char**argv); so you can use the argc (which is positive) & argv arguments. The argv array is guaranteed to have argc+1 elements. The last is always NULL. The others are non-nil, non-aliased zero-byte terminated strings. Notice that often some shell is globbing the arguments before your program is started by execve(2): see glob(7).
For example, if you type (in a Linux terminal) myprog -i a*.c -o foo.txt and if at the moment you type that the shell has expanded (by globbing) a*.c into a1.c and a2.c (because these are the only files whose name start with a and have a .c suffix in the current directory), your myprog executable main program is called with
argc==6
argv[0] containing "myprog" (so you could test that strcmp(argv[0],"myprog") == 0)
argv[1] containing "-i"
argv[2] containing "a1.c"
argv[3] containing "a2.c"
argv[4] containing "-o"
argv[5] containing "foo.txt"
argv[6] being the NULL pointer
In addition you are guaranteed (by the kernel doing the execve(2)) that all the 6 argv pointers are distinct, non-aliasing, and non-overlapping.
GNU libc gives you several ways to parse these arguments: getopt & argp. getopt is standardized in POSIX (but GNU gives you also the very useful getopt_long(3))
I strongly suggest you to follow GNU conventions: accept at least --help and --version
The fact that e.g. -f is for some option and not a file name is often conventional (but see use of -- in program arguments). If you happen to really want a file named -f (which is a very bad idea), use ./-f
Several shells have autocompletion. You need to configure them for that (and you might configure them even for your own programs).
I am currently writing my own terminal in C.
I found out, that there is multiple variants of the exec() methode, that i can use.
Its simple occurance lead me to use execv():
int main(int argc , char* argv[]){
char* dir = getcwd(NULL, 0);
char* command[] = {"echo", "Hello", "World", "!!!", NULL};
execv(dir, command);
}
From my understanding this should work. It is compiling, but nothing happens.
The path argument to execv is supposed to be the path specification to the executable file you want to run, not just a directory as returned by getcwd. From the manpage:
The initial argument for these functions is the pathname of a file which is to be executed.
In other words, you're looking for something like:
execv ("/bin/echo", command);
The code you currently have is trying to run your current directory, something that's unlikely to end well, and something you may have noticed if you checked the return value from execv along with errno: nudge, nudge, wink, wink :-)
In terms of what to do for other programs, you simply substitute their full path name for /bin/echo.
You should also be aware that exec is a family of functions, each with slight variations.
Some allow environments to be passed, some automatically search the path for your executable (depending on the name given), and some use variable argument lists rather than arrays. If you want to use the automatic path searching, you would look into execvp rather than execv, then you don't have to worry about where the executable file is located.