I've been using, in equal amounts, Fedora and Ubuntu for well over a decade now, and there's one minor but irritating difference I noticed from their installs of midnight commander. When you change dirs inside it using Fedora, then exit, it has done the chdir for you but in Ubuntu it keeps it at the place you started. Googling threw up a solution for older Ubuntus here: http://ptspts.blogspot.co.uk/2010/01/how-to-make-midnight-commander-exit-to.html but trying that fails on 16. When I say fails, I mean the commands are accepted without complaint but it doesn't change mc's behaviour in Ubuntu.
The other responses are fine, but I feel like they are unsatisfying, here is my solution, which I think is the simplest:
Put this line into your ~/.profile
alias mc='source /usr/lib/mc/mc-wrapper.sh'
Create an executable with the following content:
MC_USER=`id | sed 's/[^(]*(//;s/).*//'`
MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$"
/usr/bin/mc -P "$MC_PWD_FILE" "$#"
if test -r "$MC_PWD_FILE"; then
MC_PWD="`cat "$MC_PWD_FILE"`"
if test -n "$MC_PWD" && test -d "$MC_PWD"; then
cd "$MC_PWD"
fi
unset MC_PWD
fi
rm -f "$MC_PWD_FILE"
unset MC_PWD_FILE
Then define an alias pointing to that executable:
alias mc='. ~/.config/mc/exitcwd'
Don't forget to apply the alias:
source ~/.bashrc
Simple:
mcedit ~/.profile
Add this line at the end of file:
alias mc='source /usr/lib/mc/mc-wrapper.sh'
Type this command to execute changes
source ~/.profile
Then, to save both sides of mc windows, click at the top of MC
Options -> Panel options -> Auto save panels setup
Here, in the article Use Midnight Commander like a pro, explains how to do it.
Basically, you have to create an alias for mc-wrapper.sh.
While it's not exactly an answer to your question: just use ctrl+o to drop to the shell. It doesn't really quit mc, but that has the benefit that you can just hit ctrl+o again to go back where you were in mc.
For Ubuntu put this to .bashrc:
alias mc='. /usr/lib/mc/mc-wrapper.sh'
then:
source ~/.bashrc
(or relaunch the console)
I want to add that this only works by existing with F10. If you exit by typing exit the path will not be preserved.
Related
I've been trying to set a path to Clion directory in my computer in order to open this program with a command in terminal, but it didn't worked.
If you read this and asked yourself: "what?". I want to start a C++ project like I did with a normal text editor(I used to write codes with gedit).
I want something like, make a hello world:
Clion helloWorld.cpp &
And it will open a new project, named helloWorld, and then I can write down the code.
If it is impossible to do that, sorry.
In researching this question, I just discovered that there is an officially supported method for doing this is via CLion's Tools|Create Command Line Launcher... menu item.
Full details are posted here: https://www.jetbrains.com/help/clion/working-with-the-ide-features-from-command-line.html
Start CLion using the GUI interface, then start Terminal and run the following to find what process is running:
ps -ae| grep lion
Output
57257 ?? 0:20.45 /Applications/CLion.app/Contents/MacOS/clion
57434 ttys000 0:00.00 grep lion
So the command I need to use, in my case, to start CLion from the command line is:
/Applications/CLion.app/Contents/MacOS/clion
Then you need to pass the directory containing your project, so you could make a function like this:
function CLion { /Applications/CLion.app/Contents/MacOS/clion "$1"; }
Then you can just type:
Clion ~/CLionProjects/someProject
For Mac users, you need to add following row in ~/.bash_profile:
alias clion='open -na "CLion.app" --args "$#"'
Then from the terminal you can run CLion:
clion /path-to-your-project
If you use JetBrains Toolbox to manage your CLion (or other IntelliJ) apps like I do, you'll find that Toolbox installs CLion with a versioned pathname. This means every time you update CLion, the path to the clion.sh launcher script changes.
For Linux environments, you can use the following in your ~/.bash_profile to handle this:
alias clion="`find ~/.local -iname clion.sh | head -1` >/dev/null &" #Linux
or
alias clion='open -n "$(IFS=$'\n' && find "${HOME}/Library/Application Support/JetBrains/Toolbox/apps/CLion" -iname clion.app | head -1)"' #Mac OS X
If you upgrade your CLion you can restart your terminal or just run . ~/.bashrc to update the clion alias.
Since I installed gcc-49 on my Mac I can't get Homebrew to find the C++ compiler anymore. It always fails with error messages like:
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
Running "brew upgrade -v" spits out this:
...
==> ENV
HOMEBREW_CC: llvm-gcc
HOMEBREW_CXX: llvm-g++
...
I have no idea why Homebrew wants to use these compilers. Why can't it use the normal CC/CXX environment variables like everything else?
I already found, that by editing the formula directly like described in Using Homebrew with alternate GCC, I can change the HOMEBREW_CXX to use /usr/local/bin/g++ for example, which makes compiling formulas that need C++ work again.
But I don't want to edit every single formula by hand for the rest of my days. How can I change this HOMEBREW_CXX environment variable permanently? I tried setting them in my .bash_profile and running "export HOMEBREW_CXX=..." in the console and neither of those work, only editing the formula directly.
Does anyone have an idea?
A poor man's solution, to be sure, but this works: put an alias in your .bashrc or .bash_profile:
alias brew='HOMEBREW_CC=gcc-4.8 HOMEBREW_CXX=g++-4.8 brew'
Now, whenever you use brew it will use the compilers you want. Check that it works by doing:
brew --env
HOMEBREW_CC: gcc-4.8
HOMEBREW_CXX: g++-4.8
...
HTH
While debugging C++ code in Qt creator I get the following error
ptrace: Operation not permitted.
Could not attach to the process. Make sure no other debugger traces this process.
Check the settings of
/proc/sys/kernel/yama/ptrace_scope
For more details, see /etc/sysctl.d/10-ptrace.conf
Here a temporary solution is found: Receiving error while trying to debug in QtProject
temporary solution (won't survive a reboot):
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
But it is difficult to run the same code in terminal every time when I start my PC to use Qt.
What is the permanent solution for this?
If running Ubuntu,
The recommended way to enable the needed ptrace kernel setting (hinted by qtcreator) is to edit /etc/sysctl.d/10-ptrace.conf
sudo vim /etc/sysctl.d/10-ptrace.conf
Then change
kernel.yama.ptrace_scope = 1
to
kernel.yama.ptrace_scope = 0
Save,
then apply:
$ sudo sysctl --system -a -p|grep yama
kernel.yama.ptrace_scope = 0
run
man sysctl
for more info.
I got the answer.
Go to the location /etc with root privilege.
Find the file rc.local.
Open it in a text editor like gedit and add the following code
there
echo 0 | tee /proc/sys/kernel/yama/ptrace_scope
Restart your pc and you can see the debugger working perfectly.
I found the answer that works for me on ubuntu in below link and the credit goes to dstzcxr
https://askubuntu.com/a/501271/395583
Just uncheck (or check - run - uncheck if it is for some reason
unchecked) the box "Run in terminal" in "Projects" (on the left bar) -
"Run" tab - "Run" section.
I recently reinstalled Cygwin on my computer in order to get access to several command line elements that I was missing. I have never had previous difficulty with Cygwin, but after this reinstallation, an error message continues to appear after (almost) each command entered. For instance:
-bash-4.1$ wc m1.txt
3 [main] bash 2216 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x38D000)
-bash: fork: retry: Resource temporarily unavailable
2013930 4027950 74968256 m1.txt
Generally, the command still runs (as seen above), but not always. Occasionally, the 'error' message occurs several times in a row (the initial number "3" will then change to a "4" or "2", notably if I start a second Cygwin window.
Also, as soon as I start up Cygwin, I get the following message before the prompt:
3 [main] bash 6140 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x36D000)
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash-4.1$
At the moment, I am debating whether to uninstall/reinstall Cygwin again or just live with the error messages, but I was curious if there might be an issue that I am unaware of.
(assuming Cygwin is installed at C:\Cygwin):
Open Task Manager and close any processes that look to be Cygwin related.
Open C:\Cygwin\bin in Windows Explorer
Verify that dash.exe, ash.exe, rebase.exe, and rebaseall exist in this folder
If any of them are missing, re-run Cygwin setup and select the dash, ash, and rebase packages
right-click your C:\Cygwin folder, uncheck Read-only (if its checked), and press OK.
When an error about not being able to switch some files comes up, select "Ignore All". Wait for this process to complete.
Browse to C:\Cygwin\bin in Windows Explorer
Right click dash.exe and click "Run as Administrator". A command Prompt should appear with nothing but a $
Type /usr/bin/rebaseall -v, hit enter, and wait for the process to complete.
If you get errors about Cygwin processes running, try Step 1 again. If that still doesn't work, Restart your computer into safe mode and try these steps again.
A commenter noted that, depending on your settings, you may have to type cd /usr/bin && ./rebaseall -v instead.
Try opening Cygwin again.
This process worked for me. I hope it works for you guys too.
Source: http://cygwin.wikia.com/wiki/Rebaseall
I would like to add the following to the above answers, as it is what I had to do after reinstalling Cygwin:
Navigate to the "/usr/bin" directory (usually, C:\cygwin\bin) and right click, Run as Administrator the file: dash.exe
Then, at the $ prompt type the following, hitting enter after each line:
cd /usr/bin/
/usr/bin/peflags * -d 1
/usr/bin/rebaseall -v
What it does is, it marks the dll's as "rebase-able," and then rebases them. You have to have peflags.exe in addition to the above files (in previous answers). You may have to restart windows after doing this and you will definitely need to make sure that there are no processes nor services belonging to cygwin running. (Use task manager, kill any related processes, and then under the services tab look for any service starting with CYG and stop it.)
After doing this, I was able to get cygwin to run without any errors about dll's being loaded to the wrong addresses aka fork errors, etc.
I hope that this helps others, as it was a pain to find.
SOURCE: http://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
and the rebase README file.
To add on to other answers here, we ran into the same issue but could not run the rebase command from the ash or dash shell. However, when launching the command from the Windows cmd shell, the following worked.
cmd /c "C:\cygwin64\bin\ash.exe /usr/rebaseall -v"
-v is to get verbose output
I found another information here :
http://cygwin.com/ml/cygwin/2014-02/msg00531.html
You have to delete the database at
/etc/rebase.db* and do in a "ash" windows :
peflags * -d 1
rebaseall
It works for me on 2 servers.
I solved this problem by restarting my computer. Probably installed a driver update and kept using sleep instead of shutting down.
Experienced the same issue when loading Cygwin with cygiconv-2.dll forking and not loading successfully in the Cygwin terminal, but after turning off my AntiVirus (it was specifically Ad-aware), the issue resolved, and Cygwin worked properly.
In case you are using babun's Cygwin, after rebaseall, try launching Cygwin by executing .babun\cygwin\cygwin.bat in a Windows command prompt or Windows explorer.
This works for me (while launching babun's default console - mintty results in fork error).
I had the error on win10 and i was trying to rebase to c: before install.
then i saw that the installer was installing it instead to c:/Users/myuser
so i was coping all files from c:/Users/myuser to c:.badun
and then restart plus open badun.bat
not shure if this was wise its now duplicated XD... but then it worked again.
Rebaseing didn't help in my case. In addition to what other people suggested, I noticed that reducing the length of PATH environment variable fixed the issue for me (and for other people as well as can be seen from this answer).
This issue is intermittent in nature & I found this issue when there is network is too slow to connect to remote machine on AWS.... I have Shell script that runs through Gitbash shell & it connects to AWS EC2 instance with ssh..... Most of the time, it ran correctly but 2 out 100 times it get into this issue bash: fork: retry: Resource temporarily unavailable .... Killing the MSYS2 terminal from task manager helps to overcome with this issue....
Negative side is you need to run the scripts from the beginning...
I had the same issue on Windows 10 and the mobaxterm app (which uses cygwin) and I tried all of answers listed here however for me, the solution was to simply delete the "CryptoPro CSP" application.
I started facing this problem after upgrading to windows 10. As of now I do not see that any of the above method working.
What I am noticing is that if you start cygwin with admin right (right click and say "run as admin") then it works fine.
Or you open cmd as administrator and then launch cygwin from there, then also it runs fine.
Just reinstall cygwin and select TCL and activate EXPECT
I have 3 questions. I am making a C++ executable to launch a Perl program I made. I will compile it for Winows, Mac OSX and Linux. It's pretty much just: system("perl progam.pl");
When compiled with Mac OSX, the program starts in ~. How would I get it to start in the dir it was launched from, or is it just a problem with the compiler?
I'm using - echo -n -e "\033[0;Program\007" - in an attempt to make the windows title "Program". Is this is best way?
I'm using - echo -n -e "\033[7;30;47m" - to make the background of the window black. Is this the best way?
Thanks.
This sounds like something Finder is doing. Launching the app from a shell should work as you expect.
Use tput
See answer to 2, above.
On Mac OS/Unix, invoking system does not change the current working dir. When executing program.pl the current working directory is the same from which you executed the C++ executable. When you launch the executable using Launch Services (e.g. the Finder) the working directory should be /.
On #1 you can refer to the current directory with ./ so system("perl ./progam.pl"); should do it assuming both scripts are sitting in the same folder. ../program.pl would be one level higher.
For #1, use getcwd & then pass an explicit path to system:
cwd=getcwd(NULL, PATH_MAX);
sprintf(cmd, "perl %s/program.pl", cwd);
system(cmd);
free(cwd);
If your perl program itself relies on a specific working directory, then do this instead:
sprintf(cmd, "cd %s && perl program.pl", cwd);
This is probably a silly question, but why are you making an application to launch a perl script? Just add the following to the top of your perl script and use "chmod a+x" to make it executable:
#! /usr/bin/perl
When you use the system command from C and C++, you are basically launching the default system shell and executing the given command in that shell. Doing that is not very portable and somewhat defeats the purpose of using C or C++ (since you could simply create a shell script that does the same thing). If you want to actually do this with C++, you should probably use popen or fork+exec to launch perl. Generally speaking, it isn't nice to end users to play with their Terminal in the manner that you have proposed; most users, by default, have the Terminal configured to display the most recently executed command or their current directory or some other information of their choosing, and changing that is -- on UNIX systems such as Mac OS X and Linux -- considered improper etiquitte. If you are trying to create a terminal interface, though, you might want to look at the curses library.