Skip Menu |

This queue is for tickets about the Shell-GetEnv CPAN distribution.

Report information
The Basics
Id: 87111
Status: resolved
Priority: 0/
Queue: Shell-GetEnv

People
Owner: Nobody in particular
Requestors: mobrule [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.09



Subject: Suggested patch - new feature
Date: Sat, 20 Jul 2013 11:50:41 -0700
To: bug-Shell-GetEnv [...] rt.cpan.org
From: "Marty O'Brien" <mobrule [...] gmail.com>
Hi Dr. Jerius, New Perl programmers are often confused about how the system call interacts with the environment, and they wonder why code like this system('export foo=bar'); system('echo $foo'); behaves differently from system('export foo=bar; echo $foo'); I came across your Shell-GetEnv distribution and thought about how it could be used to get those first lines of code to do what the user intends to do. The only thing missing from the functionality of Shell-GetEnv that would let me write a wrapper function and create a drop in replacement for system is the ability to retrieve the exit status of the process. This suggested patch adds that functionality. It includes new tests and test scripts, though I neglected to patch the module documentation. Suggested patch enclosed. Marty O'Brien mob@cpan.org

Message body is not shown because sender requested not to inline it.

On Sat Jul 20 14:50:55 2013, mobrule@gmail.com wrote: Show quoted text
> Hi Dr. Jerius, > > New Perl programmers are often confused about how the system call > interacts with the environment, and they wonder why code like this > > system('export foo=bar'); > system('echo $foo'); > > behaves differently from > > system('export foo=bar; echo $foo'); > > I came across your Shell-GetEnv distribution and thought about how it could > be used to get those first lines of code to do what the user intends to do. > The only thing missing from the functionality of Shell-GetEnv that would > let me write a wrapper function and create a drop in replacement for > system is the ability to retrieve the exit status of the process. This > suggested patch adds that functionality. It includes new tests and test > scripts, though I neglected to patch the module documentation. > > Suggested patch enclosed. > Marty O'Brien > mob@cpan.org
Marty, Thanks very much for your contribution. I apologize for not replying earlier; I don't know how I missed this. If I understand correctly, you're looking for a routine which would "batch" up calls to system, returning the final(?) exit value of the shell. Rather naively, is this in line with what you're looking for? sub batch { return system( join( ';', @_ ) ); } What is the functionality in Shell::GetEnv which improves upon this? Shell::GetEnv seems too specialized for this purpose, but if there is a common core of functionality that can get split out, I'm all for it. You have quite correctly pointed out that Shell::GetEnv does not return the shell's status after the commands have been run. I'll incorporate that (based upon your code and tests). Thanks again for your contribution, and again, my sincerest apologies for having overlooked this. I appreciate the effort involved. Diab
On Tue Jul 12 12:28:02 2016, DJERIUS wrote: Show quoted text
> On Sat Jul 20 14:50:55 2013, mobrule@gmail.com wrote:
> > Hi Dr. Jerius, > > > > New Perl programmers are often confused about how the system call > > interacts with the environment, and they wonder why code like this > > > > system('export foo=bar'); > > system('echo $foo'); > > > > behaves differently from > > > > system('export foo=bar; echo $foo'); > > > > I came across your Shell-GetEnv distribution and thought about how it > > could > > be used to get those first lines of code to do what the user intends > > to do. > > The only thing missing from the functionality of Shell-GetEnv that > > would > > let me write a wrapper function and create a drop in replacement for > > system is the ability to retrieve the exit status of the process. > > This > > suggested patch adds that functionality. It includes new tests and > > test > > scripts, though I neglected to patch the module documentation. > > > > Suggested patch enclosed. > > Marty O'Brien > > mob@cpan.org
> > Marty, > > Thanks very much for your contribution. I apologize for not replying > earlier; I don't know how I missed this. > > If I understand correctly, you're looking for a routine which would > "batch" up calls to system, returning the final(?) exit value of the > shell. > > Rather naively, is this in line with what you're looking for? > > > sub batch { > > return system( join( ';', @_ ) ); > > } > > What is the functionality in Shell::GetEnv which improves upon this? > > Shell::GetEnv seems too specialized for this purpose, but if there is > a common core of functionality that can get split out, I'm all for it. > > You have quite correctly pointed out that Shell::GetEnv does not > return the shell's status after the commands have been run. I'll > incorporate that (based upon your code and tests). > > Thanks again for your contribution, and again, my sincerest apologies > for having overlooked this. I appreciate the effort involved. > > Diab
I've incorporated the gist of your patch into version 0.08_03 which I've just uploaded to CPAN. Thanks again, Diab
Not a batch function, just a function like the builtin system call, but one that wraps Shell::GetEnv so that the system call could affect your local Perl environment. That way you could run something like $ENV{foo}=bar; system("export foo=baz"); print $ENV{foo}; and the output would be 'baz'. Or you could say system("source my_vars.sh"); system("./my_script.sh"); and all the environment changes that you specify in 'my_vars.sh' would be visible in the subshell that runs 'my_script.sh'. I think these changes will make it possible to do this.
I've incorporated your suggestions into version 0.09. Please let me know if this doesn't do what you would like. Thanks!