Re: Can I write a transparent shell wrapper to start the correct build of Perl?

The first thing that comes to mind is that the only way you get that thing running with shell is if the perl in the exec line "doesn't exist."

The second thing that comes to mind is how does this script behave if /etc/host.conf is empty. Shouldn't you define HOST_PLATFORM with some kind of sane default value before you source /etc/host.conf? Could the script figure it out for itself, with 'uname -a' perhaps?

Another issue is that using variables in all capital letters in a shell script guarantees name collisions with the OS environment variables. Some other capitalization convention for those kinds of variables is preferable.

Comment on Re: Can I write a transparent shell wrapper to start the correct build of Perl?

Replies are listed 'Best First'.
Re^2: Can I write a transparent shell wrapper to start the correct build of Perl? by thparkth (Beadle) on Feb 05, 2008 at 19:05 UTC
The second thing that comes to mind is how does this script behave if /etc/host.conf is empty. It's not. If it is, the machine has bigger problems than perl not working. Shouldn't you define HOST_PLATFORM with some kind of sane default value before you source /etc/host.conf? There is no sane default value. Could the script figure it out for itself, with 'uname -a' perhaps? Not trivially. But it doesn't matter, as the host.conf file is reliable. Another issue is that using variables in all capital letters in a shell script guarantees name collisions with the OS environment variables. That's not the actual variable name. None of the paths or filenames I gave are real. Our platforms aren't really called centos4 and centos5. The main reason for this is that the real values all contain the company name, and I'd rather not get fired ;)	[reply]

Replies are listed 'Best First'.

Re^2: Can I write a transparent shell wrapper to start the correct build of Perl?
by thparkth (Beadle) on Feb 05, 2008 at 19:05 UTC

The second thing that comes to mind is how does this script behave if /etc/host.conf is empty.

It's not. If it is, the machine has bigger problems than perl not working.

Shouldn't you define HOST_PLATFORM with some kind of sane default value before you source /etc/host.conf?

There is no sane default value.

Could the script figure it out for itself, with 'uname -a' perhaps?

Not trivially. But it doesn't matter, as the host.conf file is reliable.

Another issue is that using variables in all capital letters in a shell script guarantees name collisions with the OS environment variables.

That's not the actual variable name. None of the paths or filenames I gave are real. Our platforms aren't really called centos4 and centos5. The main reason for this is that the real values all contain the company name, and I'd rather not get fired ;)

[reply]