Cannot use gcc over ssh

[Adek336]

Connect over ssh to Haiku machine (possibly ssh localhost on Haiku). Cannot use gcc: "command not found". Outside of ssh console, gcc works fine. Checked hrev35350

[mmlr]

That's because the shell isn't set up the same way as Terminals are. Terminal shells inherit the environment originally set up with the BootScript(s) while the ssh shells won't. What you're looking for is SetupEnvironment in /system/boot. Running it like this:

. /system/boot/SetupEnvironment

sets up the relevant environment variables to allow build tools to work (amongst other things). Not a bug though.

[bonefish]

I don't see why a remote login shouldn't automatically set up things in a reasonable way. There's already #2468, which is essentially about the same.

[siarzhuk]

Replying to bonefish:

I don't see why a remote login shouldn't automatically set up things in a reasonable way. There's already #2468, which is essentially about the same.

I think that ticket about SSH is more appropriate in the Haiku-Ports Trac (​http://ports.haiku-files.org/). And I'm agree with you that the "right" port of SSH must acquire the environment from the Haiku specific places too.

BTW, the same problem (but different set of environment strings in telnet session) is observed with telnet logings. And in opposite to SSH the telnetd is treated as the part of system.

[mmlr]

Replying to siarzhuk:

Replying to bonefish:

I don't see why a remote login shouldn't automatically set up things in a reasonable way. There's already #2468, which is essentially about the same.

I think that ticket about SSH is more appropriate in the Haiku-Ports Trac (​http://ports.haiku-files.org/). And I'm agree with you that the "right" port of SSH must acquire the environment from the Haiku specific places too.

BTW, the same problem (but different set of environment strings in telnet session) is observed with telnet logings. And in opposite to SSH the telnetd is treated as the part of system.

Well, since both use bash and go through /etc/profile, we could add a check there and execute SetupEnvironment if necessary. I closed the ticket mostly because I thought if at all it'd be a port issue that should be tracked at HaikuPorts. But if we generally want all shells to inherit these we could also handle it through the profile, as we provide our own file for that one anyway. Only thing I could think of being possibly problematic would be that the initial shell would also execute it as part of its profile (if it does that at all), though it doesn't look like the BootScript would do much important before launching SetupEnvironment really.