Interix SUA Community Forum

On a new install of Interix, with the pkg-complete for x64 (genuineintel), bash is... not configured as I would expect, by default. running "pkg_update -rL bash" didn't help. In particular:

It is missing the Interix PATH entries (/bin, /usr/local/bin, /opt...)

It is missing the MANPATH, TERM, and TERMCAP variables entirely (and probably others).

It is defaulting to a working directory of /dev/fs/C/Windows/System32 (location of posix.exe, probably).

Additionally, the built-in LS is acting weirdly; the command "ls /" produces the listing for /dev/fs/C/, not for / (though you can get the listing for / by asking for "ls /../../.."). /bin/ls works more-or-less as expected, but isn't used by default (see weirdness of PATH).

Launching bash from within tcsh works fine, since the inherited environment is already set up. However, launching bash from the Run dialog, the system tray, or a cmd terminal produces the unconfigured version (although it inherits the CWD from cmd).

Launching bash from the Start menu (All Programs->Subsystem for Unix...->Bash Shell) doesn't work at all, because the shortcut specifies a working directory ("Start in" field) of "C:\WINNT40\system32\" which my NT 6.1 box utterly lacks...

System: Windows 7 SP1, Enterprise edition, x64. UAC is enabled but setuid behavior and su-to-root are both allowed, and the installation was done as Administrator.

I'll start looking into it. Thanks for the info.

Thanks, Rodney. Looks like a total of 84 environment variables in bash-invoked-from-tcsh, and only 62 in bash-invoked-from-taskbar.

It appears to not be reading the profile files in /etc, probably because of the path screwup exhibited by the builtin ls. It happens in other builtins, too. For example,
Oddly enough, path autocompletion seems to work correctly. I don't know enough of the internals of bash to say why that might be.
works just fine, though.

Thanks for that additional info.

It smells like the "I know better than the libraries that ship with the system" libraries that are part it.
That's what caused (different) problems the previous release. I'd tested for those ones and they were clear.

It's weird for sure... it seems the login option is not being obeyed (the '-l' or '--login').
This is on 64-bit. On 32-bit it is obeyed. Weird because it's the same code & configuration.
It's looking less clear to find what the root of the problem is, so no time estimate (alas).

There seem to be regressions in the bash code from earlier versions (even with this at patch 42 already).
It's not interpreting command substitutions using "$()" correctly.
There's a work-around that I have (using back-ticks instead), but I'll see what else I can come up with.
This is appearing on 32 and 64 bit versions, but kicking an error at slightly different times.
Just FYI.

yeah im getting the error with $() and was doing the same thing with `` and not getting a login displaying your current directory.. how can i downgrade back to 3.2.39.2 ?

EDIT: ok never mind i installed 3.1 with apt-get and it fixed it.. still would like to know how to downgrade for in the future

Well, you can always manually download the package from the suacommunity FTP server and install it used pkg_add. There's probably a better way, but I actually don't know it.

i tried that and when clicking the link it errors "550 /src/bash: No such file or directory"

There seem to be regressions in the bash code from earlier versions (even with this at patch 42 already).
It's not interpreting command substitutions using "$()" correctly.