HOME env variable is not correctly handled by bash applet

[javacommons]

• When I set Window's HOME env variable to C:\User\user\home5 and execute "busybox bash -l", the current directory goes to C:/Users/user.

• When I execute "cd" just after "busybox bash -l", the current directory goes to the expected C:\User\user\home5.

> busybox pwd
D:/
> echo %HOME%
C:\Users\user\home5
> busybox bash -l
~ $ pwd
C:/Users/user
~ $ cd
~/home5 $ pwd
C:/Users/user/home5

• .profile seems to be read from the expected directory C:\User\user\home5.

[rmyorston]

The shell in busybox-w32 now respects $HOME when started with the -l option.

New prerelease binaries are available.

As has been reported before (issue #27) there's a quirk in how tilde expansion in the shell interacts with $HOME. This is probably wrong too, but it's an upstream issue so any fix will require coordination with them.

[javacommons]

Thank you for your quick response! I verified that "busybox_pre64.exe bash -l" goes to "C:\User\user\home5" now.

Then, I found another issue:

> busybox_pre64.exe bash -l
~/home5 $ pwd
C:/Users/user/home5
~/home5 $ ls ~/ (Hitting tab lists under C:\User\user, not under C:\User\user\home5)

When logging into busybox bash (with "busybox_pre64.exe bash -l"), prompt says "~/home5 $". That means "~/" in command line still points to "C:\User\user"; this leads to wrong file name completion. If "ls ~/ (TAB)" lists under "C:\User\user\home5" (%HOME%), bash applet is perfect (for me)!

Thanks in advance.

[rmyorston]

Your issue with the prompt and file name completion is the same as the one I mentioned above. The problem in this case is in the line editing library rather than the shell. It's also an upstream issue so it may take a bit longer to sort out.

[javacommons]

The problem in this case is in the line editing library rather than the shell. It's also an upstream issue so it may take a bit longer to sort out.

Understood. I hope some day this problem be solved too. Take your time!

[javacommons]

The problem in this case is in the line editing library rather than the shell. It's also an upstream issue so it may take a bit longer to sort out.

Understood. I hope some day this problem be solved too.

I might have found the solution for the the line editing library problem; I tested myself and it worked as expected. When you have time, please apply and check the modification below:

[Modification of libbb/lineedit.c]

static NOINLINE const char *get_homedir_or_NULL(void)
{
#if 0x1
	const char *hp = getenv("HOME");
	if (hp != NULL && *hp != '\0') {
		return hp;
	}
#endif
	if (!got_user_strings)
		get_user_strings();
	return home_pwd_buf;
}

P.S. I might have to use lookupvar() instead of getenv(), but I could not use lookupvar because of link error.

Remaining problem is that even If you change HOME variable inside bash applet session, the line edit library does not follow that change. This could be solved if I could use lookupvar() instead of getenv().

[rmyorston]

Indeed, lookupvar() is the correct way to do it, but it's a static function in ash.

I've already sent a patch upstream which allows for this. It uses the equivalent function for hush, the other shell in BusyBox (which hasn't been ported to busybox-w32).

On reflection it should probably use getenv() when the line editing code isn't being used from a shell. I'll think about this and may issue a new version of the patch.

[javacommons]

Sounds great! I'm looking forward to seeing the official release of busybox-w32 with this patch.

[javacommons]

I've already sent a patch upstream which allows for this. It uses the equivalent function for hush, the other shell in BusyBox (which hasn't been ported to busybox-w32).

Could you put the patched binary in https://frippery.org/files/busybox/prerelease/ so that I could test it?

If we must get upstream approval before exposing prerelease binary then I'll wait until then.

[rmyorston]

I've make a new upstream patch.

Since this hasn't been applied yet I've put it on the 'tilde' branch in busybox-w32. There's a binary based on this (busybox_tilde64.exe) in the prerelease directory.

[javacommons]

Since this hasn't been applied yet I've put it on the 'tilde' branch in busybox-w32. There's a binary based on this (busybox_tilde64.exe) in the prerelease directory.

Thank you very much. I tested busybox_tilde64.exe and it looks good to me! I'll use this binary for my work till the official release.

> busybox_tilde64.exe pwd
D:/
> echo %HOME%
C:\Users\user\home5
> busybox_tilde64.exe bash -l
~ $ pwd
C:/Users/user/home5
~ $ ls ~/ (TAB lists under C:/Users/user/home5 ==> OK)
~ $ export HOME=C:/Users/user
~/home5 $ ls ~/ (TAB lists under C:/Users/user ==> OK)
~/home5 $ 

[javacommons]

https://github.com/rmyorston/busybox-w32/blob/master/libbb/lineedit.c#LL264-LL270

~~Seems lineedit.c is ready for tilde mode, how about merging tilde branch into master branch.~~

[rmyorston]

Actually, support for proper tilde handling is already in master. It came via upstream rather than the tilde branch. Both have the same patch.

The latest prerelease binaries have this fix (and it will be in the next full release, whenever that may be).

[javacommons]

Actually, support for proper tilde handling is already in master. It came via upstream rather than the tilde branch. Both have the same patch.

The latest prerelease binaries have this fix (and it will be in the next full release, whenever that may be).

Thank you for your reply. Great! I checked the latest busybox_pre64.exe and it works perfect! I'll use busybox_pre64.exe until the next full release.

[rmyorston]

Closing this issue as the latest release should have the necessary fixes.