The right way to invoke a Shell || Losing Shell Variables ?!

imp2021 · 2017-01-10 18:34:13

I'd sometimes like to invoke a shell from within gvim.
I do that via x-terminal-emulator.

fancy business (lets call it the v-invoked):
:let @p=expand("%:p:h")<cr>: !x-terminal-emulator -T started_in_gvim --working-directory=<C-R>p &

I expect it to be the same shell I'm used to use, just named and opened in some directory.. (s-invoked)

$ x-terminal-emulator -T named_bugger --working-directory=/somewhere/notHOME/

(but its not! x-terminal-emulator invoked from another shell, works just fine.)

So, my python breaks in the v-invoked, throwing 'your files not ascii' errors. And also my conky I'm working on gave me:

Can't set the specified locale!
Check LANG, LC_CTYPE, LC_ALL.

I'm confused.
No such things happen when I open my Terminal the bunsen way (<W-t>) or its s-invoked.
Also my python works like a charm again when I do in v-invoked:

$ LANG=en_US.utf8

That's ok? Why is it that weird? What's a useful search term for the web?

Last edited by imp2021 (2017-01-12 07:02:17)

twoion · 2017-01-10 19:43:56

What does the environment in your freshly v-invoked shell look like?

imp2021 · 2017-01-11 08:09:03

$ env > v_invoked; cat v_invoked

XDG_VTNR=7
ORBIT_SOCKETDIR=/tmp/orbit-duck
SSH_AGENT_PID=742
XDG_SESSION_ID=1
TERMINATOR_UUID=urn:uuid: ( some id, i removed from the paste)
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/duck
QT_STYLE_OVERRIDE=GTK+
TERM=xterm
SHELL=/bin/bash
MYVIMRC=/home/duck/.vimrc
WINDOWID=94371844
OLDPWD=/home/duck
LC_ALL=
USER=duck
LS_COLORS=( i removed from the paste, for length reason )
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
SSH_AUTH_SOCK=/tmp/ ( some file i removed from the paste)
COLUMNS=113
PATH=/home/duck/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
DESKTOP_SESSION=lightdm-xsession
LC_MESSAGES=en_US.UTF-8
PWD=/home/duck/tmp/bashfix
LANG=en
PYTHONSTARTUP=/home/duck/.pythonrc
LINES=54
GDMSESSION=lightdm-xsession
XDG_SEAT=seat0
HOME=/home/duck
SHLVL=2
LOGNAME=duck
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-Vfgh6AHiiP,guid=c5c5fc91240c54ce05734ca4586cbb60
ROWS=55
VIMRUNTIME=/usr/share/vim/vim74
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=:0
XDG_CURRENT_DESKTOP=XFCE
VIM=/usr/share/vim
COLORTERM=gnome-terminal
XAUTHORITY=/home/duck/.Xauthority
_=/usr/bin/env

It differs in a few lines from my regular s-invoked bash/terminal. For instance its there this LANG=en_US.UTF-8
.bashrc loads in v-invoked, my sourced files from there seem to work (alias, functions etc.).

Maybe it's about .bash_profile? I don't seem to have such a file in ~/. (Here I'm just wild guessing.)

Last edited by imp2021 (2017-01-11 08:10:18)

ohnonot · 2017-01-12 07:41:54

i don't know why gvim makes changes "en_US.UTF-8" to "en".
if you cannot get to the bottom of this on the gvim side it actually might be a good idea to add that to .bashrc or .bash_profile or .profile (but be aware that you are effectively overriding the locale for all shells opened after login).

imp2021 · 2017-01-13 08:54:44

ohnonot wrote:

i don't know why gvim makes changes "en_US.UTF-8" to "en".

How to narrow this down?

I tried to add

env > /home/me/tmp/somefile

to /usr/bin/x-terminal-emulator
but it throws me errors.

env

Alone Doesn't echo anything from within the file..

How to check the environment before, during and past x-terminal-emulator (or any other script/function)?

..this might lead to "How does a Bash emulator work?"..im reading, but not seeing why i cant get the env from within /usr/bin/x-termina-emulator

Maybe someone can point me further then https://www.reddit.com/r/linuxquestions … ator_work/

ohnonot · 2017-01-14 11:45:07

imp2021 wrote:

I tried to add
env > /home/me/tmp/somefile
to /usr/bin/x-terminal-emulator
but it throws me errors.

what?!
this is so wrong!
why are you doing this?

anyhow, i just read a VERY SIMILAR thread on forums.debian.net....
please post output of

locale
locale -a

imp2021 · 2017-01-15 08:29:30

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ locale -a
C
C.UTF-8
en_US.utf8
POSIX

v_invoked:

duck@localhost:$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en
LANGUAGE=
LC_CTYPE="en"
LC_NUMERIC="en"
LC_TIME="en"
LC_COLLATE="en"
LC_MONETARY="en"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="en"
LC_NAME="en"
LC_ADDRESS="en"
LC_TELEPHONE="en"
LC_MEASUREMENT="en"
LC_IDENTIFICATION="en"
LC_ALL=

duck@localhost:$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
C.UTF-8
POSIX
en_US.utf8

"to narrow" (might be a language translation thing)
why was that wrong?
I just assumed something is broken. I first try to check the things that I can reach. /usr/bin/x-terminal-emulator seemed to be in reach.

I didn't find a "VERY SIMILAR thread" on forums.debian.net. Maybe you can point me out there. I'm sorry, I'm only a "I'd ask the guys that give me that out of the box working (bunsenlabs) solution" kinda guy.

regards

Head_on_a_Stick · 2017-01-15 11:21:45

imp2021 wrote:

I didn't find a "VERY SIMILAR thread" on forums.debian.net. Maybe you can point me out there.

http://forums.debian.net/viewtopic.php?f=30&t=131168

imp2021 · 2017-01-15 18:42:32

Head_on_a_Stick wrote:

imp2021 wrote:
I didn't find a "VERY SIMILAR thread" on forums.debian.net. Maybe you can point me out there.
http://forums.debian.net/viewtopic.php?f=30&t=131168

OP in this thread says "I've done it. Don't know exactly how because i did many things."

Doesn't sound much satisfying.
Also it appears on a like blank/fresh bl installation.
(No WM, DE or any other mess up, like that OP did. Just an apt-get update and gvim install. (Maybe libreoffice, zim & git, too.))

Doesn't sound 'very similar' to me. Maybe he meant some other thread.

ty anyways smile

ohnonot · 2017-01-17 07:14:06

there were at least 2 locale-related threads on debian forums when i wrote that.
but yeah, none of them fit your problem 100%.
anyhow, point is, you can always do some research on debian forums if bunsenlabs doesn't provide the solution.

anyhow, if i compare your system locale to mine, i find that the LANGUAGE variable is not defined.
mine reads:

LANGUAGE=en_IE:en

for this or any other number of reasons vim then decides to replace everything with a plain "en" - i don't know why.

i suggest going to wiki.debian.org/Locale and configure everything from step zero.
maybe you can find what went wrong along the way.

#1 2017-01-10 18:34:13

The right way to invoke a Shell || Losing Shell Variables ?!

#2 2017-01-10 19:43:56

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#3 2017-01-11 08:09:03

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#4 2017-01-12 07:41:54

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#5 2017-01-13 08:54:44

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#6 2017-01-14 11:45:07

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#7 2017-01-15 08:29:30

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#8 2017-01-15 11:21:45

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#9 2017-01-15 18:42:32

Re: The right way to invoke a Shell || Losing Shell Variables ?!

#10 2017-01-17 07:14:06

Re: The right way to invoke a Shell || Losing Shell Variables ?!

Board footer