Axel Sander writes:

>On system#2 all variables of /etc/init are set after login:
>LC_COLLATE=en_US.ISO8859-15
>LC_CTYPE=en_US.ISO8859-1
>LC_MESSAGES=C
>LC_MONETARY=en_US.ISO8859-15
>LC_NUMERIC=en_US.ISO8859-15
>LC_TIME=en_US.ISO8859-15

I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
is a symlink to "/sbin/init", which is a binary, not a shell script.

"Neil W Rickert" wrote in message
news:MsJ%i.21207$Pv2.21028@newssvr23.news.prodigy. net...
> Axel Sander writes:
>
> I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
> is a symlink to "/sbin/init", which is a binary, not a shell script.

/etc/init.d perhaps?

On Sat, 17 Nov 2007 21:57:00 GMT, Neil W Rickert
wrote:

>I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
>is a symlink to "/sbin/init", which is a binary, not a shell script.

Hmmm, I have to check this at work. I only recalled something with
"init" in it at home;-)
It's a file just containing the environment variables I mentioned
above.

Axel

On Nov 18, 8:22 am, Axel Sander wrote:
> On Sat, 17 Nov 2007 21:57:00 GMT, Neil W Rickert
>
> wrote:
> >I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
> >is a symlink to "/sbin/init", which is a binary, not a shell script.

Same here. You aren't confused : >

> Hmmm, I have to check this at work. I only recalled something with
> "init" in it at home;-)
Theres more than one init.
> It's a file just containing the environment variables I mentioned
> above.

Just a file. Is this how you collect your pay cheques? I hope not.
Anyway, it's /etc/default/init
The problem is more like you need to patch "tr" - on something as
ancient as Solaris 8, there were locale issues associated with tr..
The workaround was to use LANG=C as I recall as a last resort

On Sun, 18 Nov 2007 09:40:46 -0800 (PST), gerryt
wrote:

>Just a file. Is this how you collect your pay cheques? I hope not.
>Anyway, it's /etc/default/init
>The problem is more like you need to patch "tr" - on something as
>ancient as Solaris 8, there were locale issues associated with tr..
>The workaround was to use LANG=C as I recall as a last resort

I meant "not a binary executable" (english is not my native language
so I should've better said "text file";-)
Sorry for the delay - I was out of the office this week.
Of course you're right about the missing "default" in the path.

There is no problem unsetting the LC_ environment or fiddle around
with the PATH to use /usr/xpg4/bin executables. I was just curious why
system#1 obviously bypasses the values in /etc/default/init while on
system#2 all variables in this file are used and set. Both are Solaris
8 systems and should behave the same way...

Axel

Axel Sander wrote:
> On Sun, 18 Nov 2007 09:40:46 -0800 (PST), gerryt
> wrote:
>
>
>>Just a file. Is this how you collect your pay cheques? I hope not.
>>Anyway, it's /etc/default/init
>>The problem is more like you need to patch "tr" - on something as

> There is no problem unsetting the LC_ environment or fiddle around
> with the PATH to use /usr/xpg4/bin executables. I was just curious why
> system#1 obviously bypasses the values in /etc/default/init while on
> system#2 all variables in this file are used and set. Both are Solaris
> 8 systems and should behave the same way...

ONLY if the systems are substantially identical! Even a slight
difference in hardware or software configuration could make a very
noticeable difference.

Axel Sander writes:
>
>There is no problem unsetting the LC_ environment or fiddle around
>with the PATH to use /usr/xpg4/bin executables. I was just curious why
>system#1 obviously bypasses the values in /etc/default/init while on
>system#2 all variables in this file are used and set. Both are Solaris
>8 systems and should behave the same way...
>

System 1 probably does not bypass the values in /etc/default/init, which
are obtained early in the bootstrap sequence. It probably overrides them
later in the bootstrap sequence. Perhaps they're overridden by your shell
when you log in. This may sound like a meaningless argument, but when you
are troubleshooting (and that's what you're doing when you try to find out
why something doesn't behave as you expect), the difference between "bypass"
and "override" is important.

Why would two machines behave differently? For all the reasons you can
think of why any two machines might do so. For example, the first one
was installed at a different time by a different person, who answered the
install-time configuration questions differently. Or the first one has
a different set of utility programs installed.

Or even something as simple as the first machine has everything installed
the same, but your default PATH doesn't choose the GNU tr before the Solaris
tr as it does on the second machine.

When it comes to machine configuration, the only real way to answer the
question "why is it different" is to find out *how* it's different. In
other words, find all the files that are different between the two machines.
One or more of those will explain why the tr program you invoke with the
command:

echo "ABC" | tr '[A-Z]' '[a-z]'

produces different results on the second machine.


-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.