I'm currently moving from zsh to fish. Most of my aliases etc are pretty easy to port, but I'm running into problems with the following one:
alias idf.py='unalias idf.py; source $IDF_PATH/export.sh; idf.py'
I know in fish aliases are just syntactic sugar for functions so I started writing the following function:
function "idf.py"
source $IDF_PATH/export.fish
functions --erase idf.py
idf.py $argv
end
the export.fish script is from the esp-idf and starts complaining about needing to be sourced. After that the function gets removed correctly but idf.py can not be found:
his script should be sourced, not executed:
realpath: /home/robert/Programs/esp-idf/export.fish/..: Not a directory
.
fish: Unknown command: idf.py
fish:
idf.py $argv
^
in function 'idf.py'
Do you have any idea how I can source to the global scope from within this function?
Just going on the commit history of the project you linked to -- The ESP-IDF script you linked is the latest version, but the error you are receiving was from a bug in an earlier version of the script that has since been fixed.
The script attempts to detect whether it is being called with the source command by testing status current-command, but since you are calling it from within the function idf.py, that's the name returned, rather than source.
It was a bug, and it was fixed about two years ago by simply removing the source check.
Upgrading to the latest ESP-IDF release should take care of it.
Related
I've recently started using fish, and I needed to use a jar file for google's bundletool.
As such, I needed to set up an alias/function for bundletool, and I chose a function since it seems more "fishy".
My function is simple:
function bundletool
java -jar bundletool-all-1.12.1.jar $argv
end
The bundletool jar itself lives at ~/.local/bin, which is on my fish user path:
lase#laser-razer /m/c/U/matth [1]> echo $fish_user_paths
/home/lase/.local/bin /usr/local/go/bin /home/lase/.nvm /home/lase/.cargo/bin /home/lase/.cargo
In a regular shell, I can execute java -jar bundletool-all-1.12.1.jar, and the command runs as expected. However, in the function, fish doesn't seem to know about my fish_user_paths, and reports it cannot find the jar file.
To remedy this, I had to update my function to specify the full path:
function bundletool
java -jar ~/.local/bin/bundletool-all-1.12.1.jar $argv
end
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
Your function will run in the ordinary environment.
It will run with the current $PATH [0] and, more importantly to you, the current working directory.
What happens is this:
java -jar bundletool-all-1.12.1.jar
Will tell java to run the jar found at bundletool-all-1.12.1.jar.
Notably, fish just hands java the string "bundletool-all-1.12.1.jar", and java will then not look at $PATH. It does not care about $PATH. It simply looks at "bundletool-all-1.12.1.jar", and tries to open a file by that name.
And it will find that file, if it is in the current directory.
And that's the reason this worked for you when you executed it interactively - because you happened to be in that directory
And then you tried it with the function, but you tried it from a different directory, and so it didn't work.
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
No, giving the full path to the file instead of relying on the working directory is the right thing to do.
[0]: $fish_user_paths is just a variable you set, that fish will then take care to add to $PATH. $PATH is the actual variable that fish and other tools (including any command fish starts, if it wants to) will use to find commands.
This question already has an answer here:
Wrong path set and now .bashrc throws errors [duplicate]
(1 answer)
Closed 6 years ago.
I put an invalid path into my bashrc and now my terminal doesn't work. I've deleted my bash_profile as well as my bashrc and I still can't get it to work.
Every command I use in terminal gives me the error:
sh: parse_git_branch: command not found
This was something I had in my bash_profile for git autocompletion. The problem is once I've deleted the files using /bin/rm <file>, I can't apply my changes with source ~/.bash_profile because it's giving me errors. I've looked at this question, and this question, but I still am having no luck.
How can I fix my command line after breaking things like this?
You can export a correct PATH in your current session using a command similar to :
export PATH=/usr/local/bin:/usr/bin:/bin
After using this, you should be able to source your bashrc.
You can always change your path right on the command line for the rest of the current shell session: PATH="/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:"
Exporting the PATH won't solve your problem. It will only export the value of PATH to child shells/processes. This only achieves the same thing as resetting/changing the PATH variable from the command-line (as shown above), because your scope is limited to the current shell process (and its children) while you are working within that shell environment (working from the command-line). If you open a new terminal (start a new login shell, which is a parent process), bash will still be trying to read from the resource files (.bash_profile and .bashrc), which no longer exist.
So, we need to be able to widen our scope and tell bash that we want to make changes for all future bashes (shell processes--new shells, shells within shells, etc.), and the way that is done is by writing those statements in the resource files.
Once you set your PATH there, every shell session will spawn with those resources (all the aliases, commands, variables, and functions stored in those files), loaded, regardless of whether you export it or not, since each shell process will always consult those files before it does anything else (so they effectively pre-emptively import what you are trying to export to them).
bash is like any other script or program. You took away all its inputs and pointers and shortcuts, and now its just been made pretty dumb, so you've got to be explicit with everything you do till you can teach it where to look for stuff (give it a PATH to search) and shorten your conversations with it.
If you don't have a backup of your .bash_profile, here's one that you can use:
# This loads in the configuration in .bashrc
# Put all configuration in there!
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
And here's a .bashrc that can get you started:
export PATH="/bin:/sbin:/usr/local/bin:/usr/bin:/usr/sbin:"
I compiled some Matlab code on Centos 5.
I try to run it like this:
run_cnaseq006.sh /projects/rcorbettprj2/mutationSeq/MCR/v714/ "/home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m"
------------------------------------------
Setting up environment variables
---
LD_LIBRARY_PATH is .:/projects/rcorbettprj2/mutationSeq/MCR/v714//runtime/glnxa64:/projects/rcorbettprj2/mutationSeq/MCR/v714//bin/glnxa64:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/os/glnxa64:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64/server:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64/client:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64
??? Error using ==> run at 65
/home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m not found.
However, I can easily see that the file does exist:
ll /home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m
-rw-r--r-- 1 rcorbett users 3 Aug 13 09:10 /home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m
I tried different quotes, and no quotes, but I can't figure out why it won't execute the file. The Code works fine as uncompiled matlab code, so something funny is happening after compilation that affects the ability to identify the file.
EDIT: run_cnaseq006.sh is the auto generated shell script for running my compiled code. It is about 40 lines, so doesn't copy well into here. However, I can say it is just a wrapper to make sure all the libraries are loaded when I run my compiled code. All the compiled code I have get pretty much the exact shell script wrapper.
I was pointed to this link:
http://blogs.mathworks.com/loren/2008/08/11/path-management-in-deployed-applications/
The "run" command uses path management functions like "cd". According to the above article such activities are unsupported in compiled applications, and can create unpredictable results.
I resigned to using an alternate approach to define my runtime variables by reading the file with getline and using "eval" to load my variables into memory.
I am writing a python embedding in C++ application. The related code snippet that I declare the module of python(user-defined one) that needs to be embedded as below:
boost::python::object main_module = boost::python::import("__main__");
boost::python::object main_namespace = main_module.attr("__dict__");
boost::python::exec("import python_module", main_namespace); //This line is the culprit
However, I'm stuck when I receive the following error:
terminate called after throwing an instance of 'boost::python::error_already_set'
My user-defined python module resides in the same directory as my C++ code. When I try like to use numpythat works, the problem is that only with my user-defined one, it doesn't. What could be done in order to debug it?
EDIT:
After I include the code in try/catch block, I obtained the following compile error:
ImportError: No module named python_module
I also try to add this:
boost::python::exec("import sys; sys.path.append('/path/to/python_module.py');", main_namespace);
boost::python::exec("import python_module", main_namespace);
but not yet working.
The problem now is how do I make it known to my C++ code?
You can try a couple of things:
In your C++ app: boost::python::exec("import sys; sys.path.append('/path/to'); import python_module; del sys"), main_namespace);, or
In your shell: cd /path/to; call-your-c++-app. Then, in C++, you would need only to boost::python::exec("import python_module");, or
Set your environment variable to export PYTHONPATH=/path/to:${PYTHONPATH} and execute your program. Your C++ in this case would need only to boost::python::exec("import python_module"); as in the above solution.
The issue: You need to append the path leading to the module to sys.path and not the path to the module file itself.
Another hint: by default, Python will load modules from the current directory. If you cd there and execute your application from that directory, it should find the module on the current directory.
On a Solaris box in a "mysterious production system" I'm running a Perl script that references an environment variable. No big deal.
The contents of that variable from the shell both pre- and post-execution are what I expect.
However, when reported by the script, it appears as though it's running in some other sub-shell which is clobbering my vars with different values for the duration of the script.
Unfortunately I really can't paste the code. I'm trying to get an atomic case, but I'm at my wit's end here.
Is it possible that your script or any libraries that you are 'use'-ing mess around with the %ENV hash?
Can you run the code through the Perl debugger to see where it's going? Can you dump the pid ($$) to check if it is forking or invoking subshells?
Alternatively, you could sprinkle print statements throughout the code to narrow down at what point the environment variable is being altered, or start stubbing out components that are not likely to be relevant to hone in on the trouble spot.
1) What version of Perl?
2) Some environment variables can be clobbered by child processes, I believe. Can you do a ps?
Ok, here's what was going on:
perl itself was a red herring entirely.
The script was executing in a child shell which, when created, was re-loading rc files. Those rc files were blowing away the environment variables I had manually added during the parent shell with reference copies.
I was able to demonstrate this with a simple csh script that just echoed just echoed the environment.
De-wonkifying my rc files (which were overwrought with wonkitude) cleared up the mystical replacement.
UPDATE: The test that proved this was a "test.sh" that had a simple "set" command. It proved that the sub-shell wasn't inheriting the parent environment correctly. Oddly, when I switched my parent interactive shell to ksh, the environment began inheriting correctly.