Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
is there a non-closing version of execl() ?
I want to write to cmd line...
i found, that "execl stands for execute and leave"
My problem of understanding is the use of fork-execl() procedure in order to write to cmd line from C program:
If the brand new forked process gets closed when execl() is done, and i can only put one command to the pipe, where is the sense of this? For example i canīt even parse to a folder by "cd /sys..." and THEN do a "ls -l" because after first command the process is allready closed.
I am not sure I understand what you are trying to do, but from this and your other posts it appears that you are trying to open an interactive shell with root privs from your non-priv'd C++ application.
With regard to the execl() example in this thread, the problem may be that you are opening a non-interactive shell (i.e. not connected to a terminal) and expecting it to behave as an interactive shell (connected to a terminal).
From man bash:
An interactive shell is one started without non-option arguments and
without the -c option whose standard input and error are both connected to terminals
(as determined by isatty(3)), or one started with the -i option.
So your execl function opens a non-interactive shell, passing its args to that shell, then closes because the non-interactive shell is finished at that point - it is not interactive.
interactive shell with root privs from your non-priv'd C++ application
Exactly - im new to linux so, im not able yet to put my needs to clear words...
Actually i see, that this might be impossible by intention, since it would brake system saftyness, but on the other hand, if my code knows the password odr if the system grants paswordless sudo, i see no reason to block this aproach.
My idea was to
- fork a process
- overlay the child process with a terminal (actually didnt know terminal and shell arent the same)
- start a pipe to the shell
- make the process root by putting "su" to the pipe
- write further instructions
Yea, I think that you are bumping into the boundary between Unix design principles and your as yet incomplete knowledge.
Other than a critical reading of the man pages, which is always a good thing, I would suggest that you get the book Advanced Programming In The Unix Environment by W. Richard Stephens (current edition also covers things specific to Linux and the BSDs). That is the most complete, readable and useful single source that I know of for getting your knowledge of the system quickly up to par.
It is not always a simple matter of whether a thing can be done, it is also important whether and how it should be done.