Date: Mon, 24 Jul 2000 09:35:51 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Piotr Eljasiak <eljasiak AT neptun DOT gdansk DOT tpsa DOT pl>
cc: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>, djgpp-workers AT delorie DOT com
Subject: Re: Patch to make getlogin() examine env. var. USERNAME
In-Reply-To: <397BFE79.31739.F3F111C@localhost>
Message-ID: <Pine.SUN.3.91.1000724093125.11803C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 24 Jul 2000, Piotr Eljasiak wrote:

> After patching libc, gelogin() works very fine outside DJGPP env., 
> but unforunately not on DJGPP machine. This is for USER env. var. 
> is set to 'dosuser' in djgpp.env (if not defined in DOS) and USER 
> has higher 'precedence' in getlogin().
> 
> IMHO ideally it'd be the best to set USER DJGPP env. var. to 
> USERNAME else to 'dosuser' if USERNAME undefined.

Why not change the order of precedence in getlogin()?  If there are 
systems where USERNAME is defined, but USER is not, that would be the
logical solution, no?

I'd prefer not to change DJGPP.ENV without a good reason.

> I've tried:
> 
> 
> +USER=%USERNAME% 
> +USER=dosuser
> 
> I'm not certain if it's legal

You mean, ``valid'', not ``legal''.  ``Illegal'' is something prohibited 
by a law ;-).