In summary I source a script in /etc/profile for wide access. The script contains 80 bash function definitions.
In /etc/bash.bashrc I check if all the functions are defined.
I also perform the same check in $USER/. profile and in $USER/. bashrc
If any functions are not available I use the logger to write a message in system journal.
After log in, reading the journal does not show any errors.
Depending of my configuration I can start a terminal session in three ways :
Application launcher / Applications / System / Terminal application
Panel ( Widget ) icon Terminal application
Option 1 is the result of “Add to favorite” from “Application launcher / Applications / System / Terminal application”
Option 3 is the result of “Add to panel (Widget)” from “Application launcher / Applications / System / Terminal application”
Starting a terminal session from Option 1 or Option 2 does not show any errors.
Starting a terminal session from option 3 show an error :
**déc. 22 18:52:20 ASUS-G750JZ** JCD_SYSTEM_COMMON_BIN[4132]: /backup_sys/000_COMMON/Bin/check_export_system_common_function - LIST of ERROR : BEGIN --:: FUNCTION Number : 1 ; Function : abort_because_test ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 3 ; Function : array_contains_element ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 6 ; Function : ask_YyNn_timeout ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 8 ; Function : ask_YyYy ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 10 ; Function : config_at_next_reboot ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 11 ; Function : confirm_twice ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 14 ; Function : create_my_directory_user ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 19 ; Function : date2stamp_full ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 21 ; Function : deactivate_all_repo ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 24 ; Function : file_add_initial_ext_name ; A_FLAG : ; DEFINED : FALSE !!! ; FUNCTION Number : 25 ; Function : {truncked by system logger}
**déc. 22 18:52:20 ASUS-G750JZ** JCD_HOME_USER_STD_BASHRC[4133]: himBH - /home/user_install/.bashrc - SOURCING DONE : Nb MISSING FUNC : 32 - USER : user_install
**déc. 22 18:52:20 ASUS-G750JZ** JCD_HOME_USER_STD_BASHRC[4134]: himBH - /home/user_install/.bashrc - ¤¤ END ¤¤ - USER : user_install
I would expect that option 2 should launch your terminal directly, and now it launches should be described by its command (you should be able inspect in your menu item properties).
Option 1 should be a shortcut/symlink to option 2 so Option 1 should never be any different than what is described in option 2.
Option 3 is the wildcard which can be anything. Widgets are generally optional, and can be coded a number of different ways… Maybe it launches your terminal completely independently of your other options, maybe it is coded as a symlink like option 1. You’d have to inspect the widget closely or experiment with it to know what it does.
As for any modifications you make…
Of course bashrc modifications generally affect only the logged in User (therefor you’ll find the settings in the User’s home directory) and modifications to /etc/profile, /etc/profile.local or in /etc/profile.d/ will affect your entire system because those locations are read during system bootup, not when you login. If your settings are unexpected, then you’ll have to look at whether your various settings conflict or can harmoniously co-exist.
I am not completely sure what you are doing there. I normally use “csh” (really “tcsh”) rather than “bash” so I can’t easily check.
Here’s something to try:
In a terminal session, run:
xterm
xterm -ls
Do those give different results?
The difference between them is that the second of those command starts your shell as a login shell, while the first doesn’t. That affects shell startup.
thanks to ‘nrickert’ and ‘tsu’ for answering. I rewrite my question. When you finished leap install you got the application launcher with the tree ‘main/applications/system’ with a konsole starter option. Editing the application launcher, one can see that the command is :
konsole
This is what I called Option 2 for this starter in my thread #1 There is already a konsole starter in the favorite’s tree. Editing the favorite’s konsole starter one can see that the same command is in use.
konsole
This is what I called Option 1 for this starter in my thread #1 Now from the application launcher with a right click, you can add a starter in the panel which is called 'add to panel (Widget) This is what I called Option 3 for this starter in my thread #1 Where to find informations about :
What happens when you start konsole from kickoff ( what program is run, what config file is in use, what is the environment. )
As you cannot edit what is in panel widget what happens when you click on the konsole icon ( what program is run, what config file is in use, what is the environment. )
Although there is probably KDE documentation for Konsole,
I’d probably prefer simply looking at the contents of the Konsole package (see command below) and inspect any files that are likely configuration files, expecting to see self-documentation as comments
The environment of process most certainly depends on how it is started - as part of user “session” or as part of systemd user service, simply because then environment is inherited via completely different paths. Whether KDE tries to feed environment of user session to systemd user instance I do not know (GNOME session does it).
I checked the environments of konsoles invoked from the application starter and from the panel. In the latter the definitions from ~/.profile are missing.
Which implies that it is not started as login shell and does not source /etc/profile itself. In this case distinction between process as part of user session and as part of systemd service becomes really important - systemd does not allow function definitions so does not (re-)export them to services:
bor@bor-Latitude-E5450:~/src/systemd$ systemctl --user import-environment 'BASH_FUNC_testfunc%%'
Not a valid environment variable name: BASH_FUNC_testfunc%%
bor@bor-Latitude-E5450:~/src/systemd$
And even if name had been accepted, currently systemd does not allow newline in environment variable value.
I want to understand something.
Depending on my configuration the import of function definitions and environment variables is done in/etc/profile.local
When a user has successfully logged in
/etc/profile.local has been read/source/executed
/etc/bash.bashrc.local has been read/source/executed
~/. bashrc has been read/source/executed
~/. profile has been read/source/executed
When I run konsole from apps_starter or from panel,
/etc/bash.bashrc.local has been read/source/executed
~/. bashrc has been read/source/executed
Since/etc/profile.local is not read/source/executed again, there is no additional duplicate import that systemd could refuse.
Assuming that systemd has the possibility to prevent the transmission of function definition, it is nevertheless true that the problem comes from the difference in launchin from ‘apps_starter’ or from ‘panel’.
I created in ** application starter / apps / utilities** an application ‘COUNT_FUNC’ using this command:
As far as I know, the important difference is whether bash is started as a login shell.
You can set that in the konsole profile, where it lists the command to run. That command probably shows as “/bin/bash”. Change it to “/bin/bash -l” to force it to behave as a login shell.
One laptop with leap 15.0 and an older version of my sourced functions ( only 60 functions for 71 KiB ) and an older version of my sourced env var ( for 23 KiB )
One laptop with leap 15.1 and the current version of my sourced functions ( 81 functions for 105 KiB ) and the current version of my sourced env var ( for 24 KiB )
Older version does not show any problems on any computer when launch from App Launcher or from panel.
Current version show problems on any computer when launch from panel (No problem when launch from App launcher).
Whether the console is launched in a User context or not.
If not, then only the system environmental variables are applied
/etc/profile
/etc/profile.local
/etc/profile.d/*
If executed in a User’s context, then User-specific environmental variables are also read and combined with the system variables which might in the above locations.
User variables are located in all the easily predictable locations, typically within the User’s /home
But then the original post of this thread didn’t really ask about this, the question actually asked about graphical objects… Widgets which can have almost anything “code behind.”
The graphical object might simply be a shortcut or link to one of the two general fire and directory locations described above.
But, a graphical object might also have special flags, options or even original code, so could launch something completely different or with a special configuration.
In a nutshell,
That’s why you can’t assume anything when you click on something… It’s similar to clicking on an email link and being sent to a phishing site.
If you want to create or launch something specific, just pay attention to the details.