consistency between ssh and shell window environments?

[solarisguy]

Home FreeNAS users are unlikely to know about SSH. For them, GUI Shell is a nice place to enter commands that are occasionally required for troubleshooting or advanced maintenance.

 

[gpsguy]

It depends on when they started with FreeNAS. IIRC, 8.0.x didn't have the GUI shell.

I only use SSH, with PuTTY for the client.

Home FreeNAS users are unlikely to know about SSH.

 

[Whattteva]

Home FreeNAS users are unlikely to know about SSH. For them, GUI Shell is a nice place to enter commands that are occasionally required for troubleshooting or advanced maintenance.

Ah, that's right. A lot of users do tend to be pretty new to POSIX OS's. The GUI does take a pretty good amount of the ugly work out with a simple and cleaner interface.

 

[solarisguy]

@gpsguy, those who did not have the GUI Shell suffered through the console

 

[solarisguy]

I have updated https://bugs.freenas.org/issues/5287

Essentially Django lives in its own world, and that appears to be the FreeNAS way:

• GUI Shell is started by this https://github.com/freenas/freenas/blob/master/gui/tools/webshell.py
• environment comes from this /usr/local/www/freenasUI/settings.py
• all django to me... ;)

So I made a suggestion to modify .cshrc , since the root default shell is tcsh. And, for the safety and consistency, .bashrc and .shrc should be adjusted too. You never now, some hot heads might change the root shell :D

 

[DaPlumber]

@solarisguy: Um. Thanks, I think. I think you're correct, but I'm not a django python master wrangler either.

If you change the root shell to bash via GUI (as I have) the the Web Shell provides all the correct environment including some of my pet things like aliasing "ll" to "ls -l". So the hard work's apparently already been done.

Can anyone who can actually read/understand the code and/or preferably maintains it comment? There has to be a simple way to trigger the same settings as when opening up the GUI window and launching the shell? I mean effectively it's the same process, just start calling it from the point after the window is set up? Or am I missing something?

 

[solarisguy]

It is quite simple. There is a FreeBSD core and it uses C locale throughout.

Then Django starts and after its start it does not look back to the core. Anything it needs, as far as its environment setup, takes from this /usr/local/www/freenasUI/settings.py And that files tells FreeNAS UI to use English US and internationalization (= i18n). Among other things, internationalization means UTF-8, as opposed to ASCII, so we get en_US.UTF-8 locale in the Shell started from the GUI. That shell is wrapped in and comes directly from Django :)

SSH lives back in the FreeBSD core, Django just tells FreeBSD to start it. SSH does not take its enviroment from /usr/local/www/freenasUI/settings.py

So somebody came up with the idea of forcing the login environment to be en_US.UTF-8 http://forums.freenas.org/index.php...not-displayed-in-ssh.10590/page-2#post-103886

Good idea, however applies only to login shells. In general, the locale setup should be either done globally (so instead of C there would be en_US.UTF-8 everywhere) or in the shell startup files. Login files should only define interactive properties related to logins. So I made a suggestion to modify .cshrc , since the root default shell is tcsh. And, for the safety and consistency, .bashrc and .shrc should be adjusted too.

Similarly confused situation existed centuries ago when X11 was used... ;)

Until FreeNAS is rewritten please help by voting for bug 5287

 

[DaPlumber]

bug 5287 +1'ed.

Before I do any wheel re-inventing does anyone have any favorite environment-scraper-saver-setter utility/script? I'm hoping for something a bit more sophisticated than saving off env, set, and alias and then implementing them, because I think that's how I'm going to try for a little consistency.

Oh, and is there any way to change the guy shell window default size?

 

[solarisguy]

The wheel was invented long time ago ;) You keep your personal settings somewhere (and copy around when required). The only modification to the startup files provided by the OS or the sysadmin is to source that file of yours at the end of the default startup file. Various OSes and shells have mutually incompatible conventions, so there are no winners...

Before changing the default window size, you would probably want to resolve the bug that results in the mismatch between reported and real window sizes. If you carefully look, you would notice that it says 80x25, and the size of the black above it is 80x25, but only 80x24 is used...