[email protected] (Ludovic Courtès) writes: > No. I think tests should minimize assumptions about things that are > outside of the build tree.
I see your point. But on the other hand, it's also desirable to test that the default PATH works (which it does on any "standard" system; maybe there's even some posix standard which formally mandates standard tools in /bin or /usr/bin?). > Another option would be to have the test environment define a custom > HOME and provide an appropriate $HOME/.profile. Thoughts? That could work. I think all tests do use a custom HOME for the user processes spawned by lshd. Whether or not $HOME/.profile works will depend on the login shell used, though. We could try overriding the login shell to always be /bin/sh or /bin/bash, I guess. Or set it to a wrapper which setsup the correct PATH. I don't remember off the top of my head how you configure the login shell, possibly SHELL is inherited in the tests, just like HOME, or if there's some command-line option. >> Otherwise, we'd need some command line option to either enable >> inherit, or explicitly specify the value of PATH. > > That seems more reasonable: in practice, this would only be used for > tests, I expect, avoid bad surprises. I think such an option makes sense. Not entirly sure I want to use it in the tests by default, for the above reason: Then the default behaviour becomes untested. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ lsh-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
