Thanks for all the replies, everyone. The FAQ is correct, and I am well aware of that problem. However, we are not writing "portable code", we are writing code for HP-UX ksh88. The fact that the code now runs on RedHat Linux is a new thing and I can't change what took 10+ years to build overnight. Since that code ran fine on previous versions of RedHat Linux, why would I have modified all my scripts?
As for adding an echo alias to each script, that would be fine, but then I am still modifying many hundreds of scripts in our highly automated environment. Thats a LOT of change cumulatively and would need to be thoroughly tested... Tom - you nailed it for me in your last sentence! Thanks, Kevin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Sightler Sent: Thursday, July 05, 2007 9:26 PM To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list Subject: Re: [rhelv5-list] how to handle "echo" ? On Thu, 2007-07-05 at 22:30 -0500, inode0 wrote: > Q12 in the ksh faq addresses this issue - http://www.kornshell.com/doc/faq.html > > Of course people with such scripts still need to deal with portability > regardless. Of course. > I'm curious what sort of echo statements are in these scripts that > would result in problems if you just add an alias like echo="echo -e" > to the scripts? Actually, in our case, probably nothing, but most of the scripts are part of third-party applications and thus changing them becomes a maintenance annoyance at least until we can get our vendors to fix them. We found the symbolic link in /usr/local/bin method to be the least intrusive "fix" because it doesn't force us to change the systems default echo behavior, allows us to use the standard Redhat supported RPM's with no risk of breaking on upgrades, doesn't force us to modify dozens of scripts in the third party applications and has an extremely low probability of impacting anything else at all. Setting a system wide alias changes the default system behavior for all scripts, which is not ideal and has a slightly higher risk (admittedly still very low). Now, we'll still file bugs with these third party vendors, and most of the applications aren't "certified" on RHEL5 yet anyway, but we've had good success with this method. I obviously can't answer for Kevin, but I worked for Chevron IT for almost 6 years back in the 90's and can only imagine the complexities that he might face. He probably is only charged with providing a supported environment for running the applications and if they don't work it's his problem. He likely has little to no control over the applications themselves. He may be able to submit requests to various development and administrative groups to get them changed, but unless things are a LOT different than when I worked there that would take a long time to work through the system as those teams would need to evaluate the impact of those changes on all of the other platforms in the environment. I suspect a simple, low-risk change to RHEL5 which makes it behave like previous RHEL versions, as well as other systems (HP-UX) is probably a huge win for him. Later, Tom _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
