I want to get the status of command which i passed as a parameter to the system() function. suppose i pass "attrib +h E:/songs/lovingsong.mp3" as system("attrib +h E:/songs/lovingsong.mp3") since i know that the path give by me is not right , i.e there is no such folder songs in my E: drive so on console it says path not found.
How can i get "path not found" message in my c program or any status code ,so that i can know the command did not work.
/* system example : DIR */
#include <stdio.h> /* printf */
#include <stdlib.h> /* system, NULL, EXIT_FAILURE */
int main ()
{
int i;
printf ("Checking if processor is available...");
if (system(NULL)) puts ("Ok");
else exit (EXIT_FAILURE);
printf ("Executing command DIR...\n");
i = system ("attrib +h E:/songs/lovingsong.mp3");
//want to get status here
printf ("The value returned was: %d.\n",i);
return 0;
}
Notice that the C11 standard (read n1570) defines system in §7.22.4.8 (with its formal argument being called string below):
If string is a null pointer, the system function determines whether the host environment has a command processor. If string is not a null pointer, the system function passes the string pointed to by string to that command processor to be executed in a manner which the implementation shall document; this might then cause the program calling
system to behave in a non-conforming manner or to terminate
So there is no clear definition, according to the C11 standard, of what system does. You need to dive into the documentation of your particular C11 implementation.
On POSIX (e.g. Linux or MacOSX), system is required to run the POSIX shell /bin/sh with the -c argument followed by the string and there is a complex chapter describing what is a POSIX shell.
Perhaps you want to pass a command which is redirecting the stderr of attrib to stdout, and read that stdout produced by your attrib command. On POSIX you could use popen (with pclose) for that purpose. Maybe (and probably) your implementation has something similar: _popen. And you also need to read the documentation of your attrib command.
So your question is really operating system specific. You need to dive into the documentation of your particular operating system.
And you might simply test (before running system) that the file E:/songs/lovingsong.mp3 exists. Maybe use _access (with perhaps a race condition if that file gets removed before running attrib).
Be also aware of the $PATH variable.
PS. I don't know anything about Windows, but you did not tag your question with Windows.
Related
I was trying to write a simple program in C, to extract the files of a zip using 7zip. I tried the exec() family of functions to start 7zip but it fails with errno=22 [ENIVAL] - Invalid Arguments.
if(-1 == execl(
"\"C:\\Program Files\\7-Zip\\7z.exe\"",
"\"C:\\Program Files\\7-Zip\\7z.exe\"",
"x -y",
"myZip.7z",
NULL
)
) {
fprintf(stderr, "%s\n", strerror(errno));
}
I tried execlp(), execv(), execvp() etc., all of them fail with the same error. The only way it works is using it with system().
Running: "C:\\Program Files\\7-Zip\\7z.exe" x -y myZip.7z from the cmd works fine. It successfully extracts the contents.
Any suggestions on what I am doing wrong and how to fix this is much appreciated.
Per Microsoft's documentation:
Important
This API cannot be used in applications that execute in the Windows
Runtime. For more information, see CRT functions not supported in
Universal Windows Platform
apps.
Possible alternatives are the _[w]spawn*() family of calls:
Remarks
The _spawn functions each create and execute a new process. They
automatically handle multibyte-character string arguments as
appropriate, recognizing multibyte-character sequences according to
the multibyte code page currently in use. The _wspawn functions are
wide-character versions of the _spawn functions; they don't handle
multibyte-character strings. Otherwise, the _wspawn functions behave
identically to their _spawn counterparts.
Note that the _spawn*() family of functions tends not to handle arguments with spaces embedded in them very well - filenames with spaces may need to be passed with quote marks surrounding the filename.
My very simple C program just hangs and I don’t know why.
I am trying to make a simple executable to handle multiple monotonous actions for me every time I start a new programming session.
So I decided with something simple (below) yet every time I run it, the app just hangs, never returns. So I have to Ctrl-C out of it. I have added printf commands to see if it goes anywhere, but those never appear.
My build command returns no error messages:
gcc -o tail tail.c
Just curious what I am missing.
#include <stdio.h>
#include <unistd.h>
int main() {
chdir("\\var\\www");
return 0;
}
There are at least two problems with the source code:
It is unlikely that you have a sub-directory called \var\www in your current directory — Ubuntu uses / and not \ for path separators.
Even if there was a sub-directory with the right name, your program would change directory to it but that wouldn't affect the calling program.
You should check the return value from chdir() — at minimum:
if (chdir("/var/www") != 0)
{
perror("chdir");
exit(EXIT_FAILURE);
}
And, as Max pointed out, calling your program by the name of a well-known utility such as tail is likely to lead to confusion. Use a different name.
Incidentally, don't use test as a program name either. That, too, will lead to confusion as it is a shell built-in as well as an executable in either /bin or /usr/bin. There is also a program /bin/cd or /usr/bin/cd on your machine — it will check that it can change directory, but won't affect the current directory of your shell. You have to invoke it explicitly by the full pathname to get it to run at all because cd is another shell built-in.
Two things:
First, that's not what Linux paths look like
Second, check the return value from chdir()
ie
if (chdir("/var/www") != 0)
printf("failed to change directory");
Finally, the effect of chdir() lasts for the duration of the program. It will not change the current directory of your shell once this program finishes.
The other answers adequately cover the issues in your C code. However, the reason you are seeing it hang is because you chose the name tail for your program.
In Linux, tail is a command in /usr/bin in most setups, and if you just type tail at the command line, the shell searches the $PATH first, and runs this. Without any parameters, it waits for input on its stdin. You can end it by pressing control-d to mark the end of file.
You can bypass the $PATH lookup by typing ./tail instead.
$ tail
[system tail]
$ ./tail
[tail in your current directory]
It is a good idea to use ./ as a habit, but you can also avoid confusion by not naming your program the same as common commands. Another name to avoid is test which is a shell built-in for testing various aspects of files, but appears to do nothing as it reports results in its system return code.
i have a C program that opens an mp3 and extract the jpg artwork in the same folder. If i execute this program with no root privileges i get a crash. If i execute it with sudo it works normally.
Now, i need another C programs who launch the previous program when it needs a jpg artwork for the selected mp3.
I tried to call popen("./firstProgram test.mp3" , "r") function or system("/(absolute path)/firstProgram test.mp3") function by calling them even with sudo in the command or not and either with relative or absolute paths. But no version seems to work.
How can i launch the first program from the second one with success?
Thanks!
fork and then use execl
char sudo[]="/usr/bin/sudo";
char pbin[]="/usr/local/bin/puppet";
NOTICE("running puppet: %s %s",sudo,pbin);
errno=0;
execl(sudo,sudo,pbin,(char *)NULL);
/* we should never get as far as this */
obviously I recommend reading man execl for further info
Unix (Linux) systems have contained a C Programming Manual in them since possibly forever. Look in Section 2, "System Calls".
This Wikipedia Page explains the Unix Manual "sections"
It is section 2 of the manual you can read about "System Calls"
Try the command: man 2 setuid
This will give you the manual for the setuid() system call which I think is what you want.
That manual page will also list references to other related system calls that may be what you want.
Remember when compiling C programs and using system calls that do low-level hardware access, to use the -O2, or -O3 option to gcc. There is a mention of it in the manual.
Ultimately the setuid() system call makes a running process started by one user change the UID of that running process to be running as some other user. (For example, you may see the Apache running as "apache", even though it was started by root).
setuid(0) lets you be root.
I'm trying to learn File I/O concepts in C programming language. I'm using GNU / Linux ( Ubuntu 16.04 LTS ) and my IDE is eclipse 3.8. when I try to write in a file through fprintf() method, it doesn't create any files or if the file is even created, it doesn't write in it. I tried to fix the problem by using fflush() or setbuf(file_pointer, NULL) methods as is suggested here but still no change. I guess I'm writing the address of the file in a wrong way.
Here is the code:
#include <stdio.h>
int main(void){
FILE *file_pointer;
file_pointer=fopen("~/.textsfiless/test.txt","w+");
setbuf(file_pointer,NULL);
fprintf(file_pointer,"Testing...\n");
fclose(file_pointer);
return EXIT_SUCCESS;
}
Can someone explain what's wrong here?
On Linux, the ~ in ~/.textsfiless/test.txt is not expanded by the C library fopen... When you use ~ on the command line, it is expanded by your shell (but not by the program using it, started by the shell doing some execve(2)...) into your home directory; the expansion is called globbing. Read glob(7). You are very unlikely to have a directory named ~.
You should read Advanced Linux Programming
So you should check if fopen failed (it is very likely that it did fail). If you want to get a file in the home directory, you'll better use getenv(3) with "HOME" (or perhaps getpwuid(3) & getuid(2)...). See environ(7)
Perhaps a better code might be:
char*homedir = getenv("HOME");
if (!homedir) { perror("getenv HOME"); exit(EXIT_FAILURE); };
char pathbuf[512]; /// or perhaps PATH_MAX instead of 512
snprintf(pathbuf, sizeof(pathbuf),
"%s/.textsfiless/test.txt", homedir);
FILE *file_pointer = fopen(pathbuf, "r");
if (!file_pointer) { perror(pathbuf); exit(EXIT_FAILURE); };
and so on.
Notice that you should check against failures most C standard library (& POSIX) functions. The perror(3) function is useful to report errors to the user on stderr.
(pedantically, we should even test that snprintf(3) returns a length below sizeof(pathbuf) or use and test against failure asprintf(3) instead; I leave that test as an exercise to the reader)
More generally, read the documentation of every external function that you are using.
Beware of undefined behavior (your code is probably having some, e.g. fprintf to a NULL stream). Compile your code with all warnings & debug info (so gcc -Wall -g) and use the gdb debugger. Read What every C programmer should know about undefined behavior.
BTW, look into strace(1) and try it on your original (faulty) program. You'll learn a lot about the system calls used in it.
Most likely your call to fopen() fails. You don't have any checking in your program to ensure fopen even worked. It may not have, and this could be due to a variety of things, like you spelling the path wrong, wrong file or process permissions, etc.
To see what really happened, you should check fopen's return value:
#include <stdio.h>
int main(void){
FILE *file_pointer;
file_pointer=fopen("~/.textsfiless/test.txt","w+");
if (file_pointer == NULL) {
printf("Opening the file failed.");
return EXIT_FAILURE;
}
setbuf(file_pointer,NULL);
fprintf(file_pointer,"Testing...\n");
fclose(file_pointer);
return EXIT_SUCCESS;
}
Edit: Since your comment, you getting the path wrong is most certainly what happened. If you're executing your program from the current directory, and your file is in a folder called "textfiless" in your current directory and your file is called "test.txt", then you'd call fopen like this:
file_pointer=fopen("/textsfiless/test.txt","w+");
hello every one I want to ask that I am making a program in which i have to run shell script using c program. up till now i have separated the arguments. and i have searched that exec should be use to run shell scripts
but i am totally confused as there are many variants of exec and by reading the man pages i am unable to find which is best suitable
Also in some exec function first arg is
path
and some have
pointer to file
what is the difference and what should i write in place of it.kindly guide me
thanks
Running a shell script from a C program is usually done using
#include <stdlib.h>
int system (char *s);
where s is a pointer to the pathname of the script, e.g.
int rc = system ("/home/username/bin/somescript.sh");
If you need the stdout of the script, look at the popen man page.
#include <stdio.h>
#include <stdlib.h>
#define SHELLSCRIPT "\
for ((i=0 ; i < 10 ; i++))\n\
do\n\
echo \"Count: $i\"\n\
done\n\
"
int main(void)
{
puts("Will execute sh with the following script:");
puts(SHELLSCRIPT);
puts("Starting now:");
system(SHELLSCRIPT);
return 0;
}
Reference:
http://www.unix.com/programming/216190-putting-bash-script-c-program.html
All exec* library functions are ultimately convenience wrappers over the execve() system call. Just use the one that you find more convenient.
The ones that end in p (execlp(), execvp()) use the $PATH environment variable to find the program to run. For the others you need to use the full path as the first argument.
The ones ending in e (execle(), execve()) allow you to define the environment (using the last argument). This way you avoid potential problems with $PATH, $IFS and other dangerous environment variables.
The ones wih an v in its name take an array to specify arguments to the program to run, while the ones with an l take the arguments to the program to run as variable arguments, ending in (char *)NULL. As an example, execle() is very convenient to construct a fixed invocation, while execv* allow for a number of arguments that varies programatically.