Opened 13 years ago
Closed 3 years ago
#7682 closed bug (fixed)
getenv("USER") inconsistent for Terminal and Tracker
Reported by: | ttcoder | Owned by: | leavengood |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta3 |
Component: | Servers/launch_daemon | Version: | R1/Development |
Keywords: | getenv $USER | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
PrefServer (used by e.g. SoundPlay 4.9.15 and probably also the 4.7.3 build that's available from bebits) depends on variable $USER for calculating the filename of the preferences file. In other words, based on that variable it will create a file with the name e.g. "pref0:user:application:x-vnd.marcone-sndplayTT". But this piece of code..
void Preference::PrepareTransfer() { .. user=getenv("USER"); if(user) AddString("_prefserver:user",user); else AddString("_prefserver:user","<Mr.X>"); .. }
... behaves differently when run in Terminal (for debugging purposes) or when run normally (from Tracker): in Tracker the getenv() call returns NULL and as a result the filename ends up having "mister X" in it, so as a user, you're led to believe your preferences have been discarded (though in fact there's just two sets maintained at once).
This behavior of getenv() is not necessarily a "bug" per se, but it's clearly something that varies from BeOS (on BeOS 5 the variable is the same in either case; don't know if it was "null" in both cases or "non-null" in both cases but it was consistent).
I've hardcoded the 'username' inside PrefServer as a workaround for myself, so no big incentive to fix this... Filing a ticket in case it's useful to others tho.
This is hrev41843 by the way.
Change History (6)
comment:1 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|
comment:3 by , 6 years ago
Not sure.. Also #12534 might be related (though that one deals with spawns from input_server instead of spawns from tracker/terminal ?).
comment:4 by , 4 years ago
Component: | System/POSIX → Servers/launch_daemon |
---|---|
Owner: | changed from | to
Status: | new → assigned |
I think #12534 is related and I have taken that ticket after some discussions in the forums. I will take this one too. This one should at least be fixable by moving USER and some other important environment variables into the launch_daemon. The launch_daemon does know the user due to the session information, but it does not set the environment variable. That is set by the /etc/profile
shell script.
comment:6 by , 3 years ago
Milestone: | Unscheduled → R1/beta3 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Fixed in hrev55130.
Move POSIX compatibility related tickets out of R1 milestone (FutureHaiku/Features).