Greetings and pardon the lengthy title,
To preface: I solved an issue where after downloading LibreOffice, the splash screen would show up, but nothing would happen afterwards
Below is the solution that fixed my issue:
Step 1. SAL_DISABLE_OPENCL=1 soffice
Step 2. libre office should open - open Tools -> Options -> LibreOffice -> OpenCL and disable the option "Allow use of OpenCL"
That being said, I'm trying to understand what happened in step 1. It appears to me that we are opening a subshell via the soffice command with the variable SAL_DISABLE_OPENCL changed in the context of said subshell
I've never seen or read about this before, and gave up trying to google the correct string of words. Does this concept have a name? I tried soffice --help but there is nothing to indicate this syntax
Any help is greatly appreciated, thanks!
Running SAL_DISABLE_OPENCL=1 soffice runs the program soffice passing to it the environment variable SAL_DISABLE_OPENCL set to the value 1. It does not run a subshell, it is run on your current shell. This syntax is described in the bash manual:
The environment for any simple command or function may be augmented temporarily by prefixing it with parameter assignments, as described in Shell Parameters. These assignment statements affect only the environment seen by that command.
That environment variable is a value treated specially by LibreOffice to force that option to be disabled.
Related
I'm currently an intern that's out of their depths here, this is really my first time using Linux, and everything I know comes from basic level tutorials.
I was asked by my boss today to install a program, and I'm following this tutorial on it, but am stuck at the Path part of it.
Solved
Every time I try to do this:
~$ export DTITK_ROOT=${autofs/cluster/name/MyUsername/more/path/DTI-TK/dtitk-2.3.1-Linux-x86-64}/dtitk
Like it told me to.
I get:
bash: DTITK_ROOT=${autofs/cluster/name/MyUsername/more/path/DTI-TK/dtitk-2.3.1-Linux-x86-64}/dtitk: bad substitution
Thank you user Muon
In bash, the ${} syntax can be used to substitute in the value of a previously defined variable, and you've enclosed an explicitly typed-out path within it, so bash is looking for a variable called path/MyUsername/more/path/DTI-TK/dtitk-2.3.1-Linux-x86-64 and not finding it. It should work if you run the command without the substitution:
$ export DTITK_ROOT=/path/to/dtitk
Actually when i open the terminal i got this default string:
username#hostname:~
I want to replace the above string whit this one:
<myprgrogram>:~
How can i do this?
I'm developing in C on GNU/Linux).
Thanks in advance!
You need to set up your prompt as detailed here (I'm assuming you're using bash).
There are numerous options and capabilities. See here for a gallery of examples.
If you mean current path, then add the below line to your .bashrc file.
export PS1='<$PWD>:'
You can change an environmental variable using setenv/putenv from the standard library (stdlib.h), see "man setenv".
However, when the program ends the variable won't be saved.
I'm looking for a way to start an application from within Matlab. The thing is, my Matlab script saves some results to a file, which should then be opened in the associated application (Blender in this case).
I'm familiar with commands like
system('program_name')
or
!program_name
and some other ways, but the thing is, the application is started with the Matlab PATH, so it looks inside the Matlab directory for all kinds of libraries it needs. For instance:
>> !blender
blender: /usr/local/MATLAB/R2011a/sys/os/glnx86/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by blender)
Is there some way to start an application, which uses the global (system) PATH?
A moment ago I thought I found a tweak, namely starting a terminal from within Matlab, with some arguments (Blender filename.blend).
system('terminal -x blender /home/pieter/Red.blend')
This did work a couple of times, but now I'm getting errors after executing this command 20 times or so...
>> system('terminal -x blender /home/pieter/Red.blend')
(terminal:10982): GLib-CRITICAL **: PCRE library is compiled without UTF8 support
(terminal:10982): Terminal-CRITICAL **: Failed to parse regular expression pattern 0: PCRE library is compiled without UTF8 support
I'm using Arch Linx, by the way.
Edit:
Well, I just thought of a rather dirty solution. Matlab uses the environment variable
LD_LIBRARY_PATH
For the paths to the necessary libraries:
getenv('LD_LIBRARY_PATH')
/usr/local/MATLAB/R2011a/sys/os/glnx86:/usr/local/MATLAB/R2011a/bin/glnx86:/usr/local/MATLAB/R2011a/extern/lib/glnx86:/usr/local/MATLAB/R2011a/runtime/glnx86:/usr/local/MATLAB/R2011a/sys/java/jre/glnx86/jre/lib/i386/native_threads:/usr/local/MATLAB/R2011a/sys/java/jre/glnx86/jre/lib/i386/client:/usr/local/MATLAB/R2011a/sys/java/jre/glnx86/jre/lib/i386
So I could save this information to a variable (e.g. MatlabPath):
MatlabPath = getenv('LD_LIBRARY_PATH')
and then before I call blender do this:
setenv('LD_LIBRARY_PATH',getenv('PATH'))
Which makes Matlab use my system libraries. Then after the program has started, re-assign the old value to LD_LIBRARY_PATH:
setenv('LD_LIBRARY_PATH',MatlabPath)
So... it is a solution, but if anybody knows a cleaner way of solving the problem, let me know.
As I indicated in my Edit above, this could be a solution:
% Save library paths
MatlabPath = getenv('LD_LIBRARY_PATH');
% Make Matlab use system libraries
setenv('LD_LIBRARY_PATH',getenv('PATH'))
disp('Starting Blender...')
system( ['blender ', Directory, FileName, '.blend'] )
% Reassign old library paths
setenv('LD_LIBRARY_PATH',MatlabPath)
However, with the other way to start an application, you can immediately return to Matlab after starting it:
% Start Blender and immediately return to Matlab
!blender Geometry.blend &
The ampersand (&) is the key to immediately return to Matlab after starting the application , but starting Blender this way I cannot provide a variable FileName like I can do with system(...).
So, anybody got a clue on how to
use !program_name with a variable filename
or
use system(program_name) with an option such that Matlab just starts the application (and doesn't wait with returning until the application has been closed)
Just run command in MATLAB:
setenv('LD_LIBRARY_PATH',[getenv('PATH') getenv('LD_LIBRARY_PATH')])
It appends matlab library in system library.
You can actually clear out the LD_LIBRARY_PATH variable in your system call, like this:
system('LD_LIBRARY_PATH=; blender');
(Note that this most likely depends on the command syntax of the shell that's launched internally by MATLAB. The above should work for Bash).
After I make changes in .bash_rc or .bash_profile, when I start GNU screen, it doesn't recognize those changes.
I can
source ~/.bash_profile
and it works for the current screen window I have open, but I have to do that for every screen window I have open.
How do I get screen to read my latest changes in my bash configuration?
If you want screen to always treat your shell as a login shell, and source the same files that would be read if just started a new shell normally, add the following to ~/.screenrc (or maybe ~/.byobu/.screenrc, as pointed out in the comment):
shell -$SHELL
This way, you don't need to manually tell it to source your files each time you start a new screen. Though you would have to if you just made changes and wanted those changes to be reflected in your current screen.
The documentation for this (and lots of other screen details) can be found here. Basically, shell is a command to screen telling it to run the following when it needs to create a new shell. $SHELL is the usual variable holding the path to your preferred shell. And the dash - in front of $SHELL indicates that it should be run as a login shell (which will typically mean it sources your ~/.bash_profile, etc.).
It's worth pointing out, however, that screen defaults to just inheriting most environment variables from the shell where you start screen; and a login sub-shell may alter some environment variables in unexpected ways. I ran into a situation where elements of my $PATH were basically permuted. I solved the problem thanks to this particularly excellent answer on superuser.
You may notice the source command available. It's important to note that this sources a file of screen commands, rather than shell commands. Other relevant (screen) commands include eval and exec.
You have to do it in each screen that you have open since they are all different shells. If you need the change every time a new shell is opened, I suggest you put the changes in ~/.bashrc instead.
Apparently, you can send a command to all windows at once using this syntax:
C-a :
at "#" stuff "source ~/.bash_profile^M"
I have a simple command in a Linux shell script (say foo.sh). In it I do this:
export INSTALL_DIR=/mnt/share/TEST_Linux
I run the script with:
> sh foo.sh
When it finishes I try to get the variable but the value is blank.
> echo $INSTALL_DIR
If I type the command directly the exported var becomes global to the opened terminal window. I'm using Ubuntu.
Setting environment variables is local to the child bash process running your script. To achieve what you want, you need to source it like this: source foo.sh. It means that it's run by your main bash process. Then, the setting of a variable will remain after the script is finished.
The variable is exported only in the new shell you are starting. You probably want to execute your script with source.
source foo.sh
I don't know the answer but i know how to overcome it.
# source ./foo.sh
# echo $INSTALL_DIR
And it's like magic.
I think it's because that script gets executed in it's own "shell". Not sure.
Because the process you are running (the shell running your script) can do whatever it wants, but its actions won't affect the parent process (your current shell).
A somewhat weird analogy would be: I can take 5 tequila shots and my environment will become blurry and gravity laws would be affected according to my perception. But to my father, his environment is the same, he doesn't get drunk because of my actions.
If you want that variables created/altered in your script affect your current shell, you should source the script as other answers pointed out. Please do note that doing this also may change the resulting working dir in your shell if the script does cd /whatever/path, that any other functions setted, but also altered or removed, would get affected in the same way in your shell.
A really weird and not very good analogy would be if I take 5 tekila shots and then my father kills me and drinks my blood.
Am I disturbed or what? ;-)