Re: Set env variables as part of a command

The problem is in order to do it properly the environment variables DASP and DASU need to be set which are for an encrypted password and username respectively.

Passing passwords via environment is as insecure as via command line. But I guess that's nothing you can change. (Else, try passing the password via a file handle to an anonymous pipe.)

For setting environment variables for a child process, try something like this:

#!/usr/bin/perl

use strict;
use warnings;

my $pid=fork();
defined($pid) or die "Can't fork: $!";
if ($pid) {
    # parent
    print "Parent waiting for the child ...\n";
    waitpid($pid,0);
    print "Child has exited, exit code = $?\n";
} else {
    # child
    chdir('/tmp') or die "Can't chdir to /tmp: $!";
    %ENV=(); # completely clear environment, for shorter demo output, 
+maybe also for security
    $ENV{'PATH'}='/bin:/usr/bin';
    $ENV{'FOO'}='foo fofoo fofofooo';
    $ENV{'BAR'}='bar bar barrrrrrrrrk';
    exec($^X,'-e','print "* Hello from a new perl\n";print `pwd`;print
+ "* $_=$ENV{$_}\n" for sort keys %ENV; print "* bye\n"')
        or die "Can't execute $^X: $!";
    # not reached
}
[download]

Output:

>perl envchild.pl
Parent waiting for the child ...
* Hello from a new perl
/tmp
* BAR=bar bar barrrrrrrrrk
* FOO=foo fofoo fofofooo
* PATH=/bin:/usr/bin
* bye
Child has exited, exit code = 0
>
[download]

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re: Set env variables as part of a command Select or Download Code

Replies are listed 'Best First'.
Re^2: Set env variables as part of a command by devilock76 (Novice) on Feb 18, 2017 at 17:42 UTC
I like that, thank you. It will have to wait till Monday till I can try it. So forking the process is that like creating a subshell or a sub perl process I am in. Sorry if I am being dense, but like I said what perl I have is rusty unfortunately.	[reply]
Re^3: Set env variables as part of a command by afoken (Chancellor) on Feb 18, 2017 at 18:08 UTC
So forking the process is that like creating a subshell Excatly. That's the beauty of fork+exec, inherited from C. (Things are quite different on Windows. Perl emulates fork and exec, which makes some things quite messy.) fork() creates an exact clone of your currently running process, including environment, file handles and all data, except for process ID and parent process ID. (Most operating systems now use a copy-on-write mechanism, so that immediately after fork(), both process use exactly the same data. The first memory write in parent or child process transparently creates a real copy of the affected memory page. But that's an implementation detail. In the old days, fork() did a complete copy.) And yes, a successful fork() returns twice: once in the parent process, returning the process ID of the child process, and once in the child process, returning 0. exec() replaces the current process with another executable. Again, everything but the actual executable <UPDATE>and signal handlers</UPDATE> stays unchanged. Things like file handles, environment, and even the process ID stay the same. Command line arguments do change, to those passed to exec(). <UPDATE>Non-ignored signal handlers are reset to defaults.</UPDATE> Between fork() and exec(), in the (temporary) child process, you can change every aspect of the process you want: current directory, environment, file handles (for things like redirection), current user, current group. It's so simple that fork() does not even take arguments, and exec() just needs the name of the executable and the new command line arguments. Compare that with CreateProcess(), requiring no less than 10 arguments, four of them pointers to structures with 2 to 18 members, so that you effectively pass more than 30 parameters to CreateProcess(). Do you think that's sufficient? No, sorry. If you want to run a process as a different user, you need another function called CreateProcessAsUser(), taking 11 arguments. Obviously, that's still not sufficient, there are two more functions CreateProcessWithLogonW() and CreateProcessWithTokenW(). Don't ask me what happens there, I simply don't want to know that. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^3: Set env variables as part of a command by devilock76 (Novice) on Feb 18, 2017 at 18:00 UTC
Ok so yeah googled, learned what fork does. Let me ask another probably basic question I could not find in some googling. When I fork the program I execute I need to create an array. I need to return that array to the parent process. How would one do that?	[reply]
Re^4: Set env variables as part of a command by afoken (Chancellor) on Feb 18, 2017 at 18:19 UTC
When I fork the program I execute I need to create an array. I need to return that array to the parent process. How would one do that? By serialising and unserialising. Create the array in the child process, write it to a file handle of a pipe, and read that pipe in the parent process. Perl wraps that in `open('-\|')` / `open('\|-')` See perlipc, especially section "Safe Pipe Opens". For simple arrays of simple strings not containing control characters, writing each string on a new line might be sufficient. Otherwise, use Storable, JSON, XML, YAML or something like that. Update: You might need to fork once again from your first child to be able to "return" an array after the external program has finished. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]