readonly environment variables not obtainable (SOLVED)

[rikky]

Hello,

I have two programs, one BaCon, one Bash.

bash:
echo $EUID
BaCon:
PRINT GETENVIRON$("EUID")
The Bash program gives me, in my case '1000', or if I'm superuser '0', But the BaCon program gives me nothing.
An empty ""

I have investigated the mater, and it appeared that there are two kinds of environment variables.
Normal environment variables like $HOME, which you can change, and hardcore environment variables, which you cannot change.
$EUID is a hardcore environment variable.

The normal variables can be obtained by
envWhile the hardcore variables can be obtained via
readonly
What strikes me as odd is that if I 
PRINT EXEC$("readonly")I get nothing, an empty "".

Also
PRINT EXEC$("echo $EUID")gives me nothing.

Which I cannot understand.
I run the BaCon script in the exact same environment as the bash script.
I've tested lxterminal and xterm.
Both have the same behaviour.

How can that be?

Luckaly I only need $EUID, which also can be obtained via 
PRINT EXEC$("id -u")Which works in both, Bash and BaCon.

Best regards,
Rik :°)

[bigbass]

hello rikky

environmental variables
can spam or overwrite your system env
if not carefully used

lets say bash code has strings like $this
and bacon has that$ notice the left and right placement of the $
this gets in the way also when switching environments

because you are running a compiled bacon app
you could also do this


this is a low level way of doing it and have it work in bacon too
and would be easy to make an official bacon command with it

ALIAS getuid() TO GETUID



IF GETUID == 0 THEN
PRINT "you are  running as the root user "
ELSE
PRINT "you are NOT running as the root user "
END IF






what You used here is taking from bash
running the id command this also works
but it is run in a shell or system call
PRINT EXEC$("id -u")

they both work

Joe

[vovchik]

Dear Joe,

Thanks for the example. I also like:

ALIAS getuid TO EUID

which will do the same thing. Maybe Peter might consider including EUID as a reserved system var...

With kind regards,
vovchik

[bigbass]

Yes vovchik
I just did that and saw your post
we could also just do IF GETUID == 0 THEN ....
and save a step

thanks!
Joe

[rikky]

ALIAS getuid() works flawlessly.
Nice one.

I think however that including EUID as a reserved system variable into BaCon wouldn't serve it's purpose.
For there are so many read only variables, and every system has different ones.

A GETREADONLY$("somevar") would be nicer.
Or that they can be obtained via the old GETENVIRON$ too.

But I suppose there are workarouds for the other read only variables also.

The point is, that I do not understand why EXEC$("some code") doesn't work, when the same code in bash works perfectly, in the same shell.

It's beyond my imagination how this is possible.

Rik :°)

Edit : I do not understand the 'IF GETUID == 0'
Doesn't work aroud here. (Belgium:-)

[bigbass]

Hello rikky


bash system wide environmental variables
if they are part of the env ( GLOBAL vs LOCAL)
can be used in this way also

hope this can be useful still
I know it is not a complete answer
going into all the details yet


Joe


DECLARE something$ TYPE STRING

something$ = EXEC$("echo  $HOME")
PRINT "Home ",something$

something$ = EXEC$("echo  $LANG")
PRINT "Language ",something$

something$ = EXEC$("echo  $USER")
PRINT "user ",something$

something$ = EXEC$("echo  $DESKTOP_SESSION")
PRINT "Desktop ",something$




TERMINAL OUT

Home /home/joe

Language en_US.UTF-8

user joe

Desktop xubuntu


[bigbass]

here are two more one in bash

and one calling a low level C function

I was working on these today fixing some old code that
wouldn't compile


DECLARE result$ TYPE STRING
'---  Bash version  
result$ = EXEC$("bash --version | head -1")
BASH$ =  result$
PRINT BASH$



DECLARE LIBC_VERSION$ TYPE STRING
LIBC_VERSION$  = gnu_get_libc_version()
PRINT "LIBC VERSION ", LIBC_VERSION$



TERMINAL OUT


GNU bash, version 4.4.19(1)-release (arm-unknown-linux-gnueabihf)

LIBC VERSION 2.27




[rikky]

Jes, I understand.
But now this:

Bash:
echo BASHOPTS : $BASHOPTS
echo BASHPID : $BASHPID
echo BASH_COMPLETION_COMPAT_DIR : $BASH_COMPLETION_COMPAT_DIR
echo BASH_VERSINFO : $BASH_VERSINFO
echo PPID : $PPID
echo SHELLOPTS : $SHELLOPTS
OUTPUT:
BASHOPTS : cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASHPID : 6507
BASH_COMPLETION_COMPAT_DIR :
BASH_VERSINFO : 4
PPID : 924
SHELLOPTS : braceexpand:hashall:interactive-comments

BaCon:
PRINT "BASHOPTS : " & CHOP$(EXEC$("echo $BASHOPTS"))
PRINT "BASHPID : " & CHOP$(EXEC$("echo $BASHPID"))
PRINT "BASH_COMPLETION_COMPAT_DIR : " & CHOP$(EXEC$("echo $BASH_COMPLETION_COMPAT_DIR"))
PRINT "BASH_VERSINFO : " & CHOP$(EXEC$("echo $BASH_VERSINFO"))
PRINT "PPID : " & CHOP$(EXEC$("echo $PPID"))
PRINT "SHELLOPTS : " & CHOP$(EXEC$("echo $SHELLOPTS"))
OUTPUT:
BASHOPTS :
BASHPID :
BASH_COMPLETION_COMPAT_DIR :
BASH_VERSINFO :
PPID : 10551
SHELLOPTS :
Heee PPID works, but  'env | grep PPID' is empty.
The rest doesn't work.

Rik :°|

[rikky]

Hmm, strange that the PPIDS defer.
I am calling the scripts out of the same terminal.

:°(

Ah, I see
PRINT CHOP$(EXEC$("ps -p $PPID -o comm=")

Gives me the name of my BaCon script.

While the 'ps -p -o comm=' from the bash PPID gives me 'bash'

:°)

[Pjot]

Hi rikky,

There seems to be a misunderstanding about the concept of "environment". The variable "EUID" is set by the BASH shell and is only valid within that shell. But that doesn't mean EUID is part of your environment.

So what is "environment" then? You can check your environment by the issuing "env" utility on the command line:

# env

As you may notice, the output will not show the EUID variable. Neither one of the other BASH variables. Why not? Because the environment is the set of variables which affect command execution and therefore is shell independent. So the environment relates to libc in general, rather than a specific shell. See "man 7 environ" for more information.

If you want to see particular BASH variables then you have to fetch them with BASH builtin commands, like 'echo' or 'readonly', as you mention yourself. So this works:

PRINT EXEC$("echo $EUID")
PRINT EXEC$("echo $BASH_VERSION")

But the following does not work:

PRINT GETENVIRON$("EUID")
PRINT GETENVIRON$("BASH_VERSION")

Again, reason being that these variables are BASH-specific and need to be obtained from an actual bash shell. The EXEC$ function invokes such a shell and therefore can return the variables.

HTH
Peter

[rikky]

Hmm, I'm realy sorry to say this, but on my system somehow this EXEC$("echo $readonly_variable") doesn't work.
I'm using : Debian_Stretch_Raspbian_2018.03, which is the latest official Raspbian to my knowledge.

I have this BaCon Script (print_readonly.bac):

PRINT "BASHOPTS : " & CHOP$(EXEC$("echo $BASHOPTS"))
PRINT "BASHPID : " & CHOP$(EXEC$("echo $BASHPID"))
PRINT "BASH_COMPLETION_COMPAT_DIR : " & CHOP$(EXEC$("echo $BASH_COMPLETION_COMPAT_DIR"))
PRINT "BASH_VERSINFO : " & CHOP$(EXEC$("echo $BASH_VERSINFO"))
PRINT "PPID : " & CHOP$(EXEC$("echo $PPID"))
PRINT "SHELLOPTS : " & CHOP$(EXEC$("echo $SHELLOPTS"))
PRINT "UID : " & CHOP$(EXEC$("$UID"))
PRINT "EUID : " & CHOP$(EXEC$("$EUID"))
PRINT
PRINT "ps -p " & CHOP$(EXEC$("echo $PPID")) & " -o comm= : ";
PRINT CHOP$(EXEC$("ps -p $PPID -o comm="))
See, all with EXEC$'s.
And this is the response :

BASHOPTS :
BASHPID :
BASH_COMPLETION_COMPAT_DIR :
BASH_VERSINFO :
PPID : 10096
SHELLOPTS :
UID :
EUID :

ps -p 10104 -o comm= : print_readonly

I can hardly imagine that this is a Raspbian thing.

Sorry, 
Rik :°(

Edit: You can see that only $PPID works, but that does not give the real $PPID,
namely the pid of the program calling the BaCon script, but the pid of the Bacon program itself.

[Pjot]

Hi rik,

These lines will not work:

PRINT "UID : " & CHOP$(EXEC$("$UID"))
PRINT "EUID : " & CHOP$(EXEC$("$EUID"))

There should be an "echo" in there as well, of course

Apart from that, on my Mageia Linux with the XFCE desktop all lines work and return a value. As mentioned, the "EXEC$" function uses the bash shell for execution, but it depends on your system.

The "EXEC$" is based on the C command "system" which uses "/bin/sh" to execute commands. On my Linux version, "/bin/sh" is a symlink to BASH:

[peter@host ~]$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 dec 28  2018 /bin/sh -> bash*


Most likely, in your Raspberry the "/bin/sh" points to something else. Can you post the output of "ls -l /bin/sh" here?

If your "/bin/sh" points to some other shell it will explain your empty results.

BR
Peter

[rikky]

Ah, I see.

The output of 'ls -l /bin/sh' is :
lrwxrwxrwx 1 root root 4 Jan 24  2017 /bin/sh -> dash
The first line of 'man dash' , chapter 'description' says :
dash is the standard command interpreter for the system.
The internet learns that it is quicker at system boot time.
I suppose this is important on a Raspberry pi. 

So I leave the symlink to dash.

Anyway, thanks for solving this problem, and doing all the effort.

Rik. :°)


 

[vovchik]

Dear rikky,

I changed the symlink to bash on my two RPI3s and everything has bee working fine for at least two years. You can safely do that.

With lind regards,
vovchik

[Pjot]

Rikky,

Alternatively, some of the variables can be queried with a workaround:

PRINT "BASHOPTS : " & CHOP$(EXEC$("bash -c \"echo $BASHOPTS\""))
PRINT "BASH_VERSINFO : " & CHOP$(EXEC$("bash -c \"echo $BASH_VERSINFO\""))
PRINT "EUID : " & CHOP$(EXEC$("bash -c \"echo $EUID\""))

Of course, the output relates to the "bash" which is started in front of the echo. Therefore, the PID will be the PID of that bash shell, and not the PID of the shell running the BaCon program.

BR
Peter