Simple one here guys, I remember there was a key that you could press in terminal to fill out the folder name for you when changing directory, saving you have to type out a huge folder name and escaping in the spaces.
cd mydir/ccp... ..... .......
I can't find it on google, does anyone know the key/key command I'm taking about?
Are you talking about completion? In bash (any many other shells) Tab is the key for completion.
Its the TAB key (assuming you are using bash shell in Terminal on Mac OS X).
Related
My apology for the "newbie trouble" that I created for myself & apology for my poor command of computer lingo
I am running a Windows 7 laptop and have a big text file (~4Gb) that I need to find certain string.
Most programs in Windows 7 cannot handle the task (file too big to open in any program in the Microsoft suite), so I downloaded cygwin and tried to grep the specific string.
The problem is
(a) the 4 Gb file is stored in the desktop of my non-admin account.
(b) I assume cygwin runs in the admin account (although I use the desktop cygwin icon to launch the environment). The reason being that under cygwin, I see the handle A#Admin-THINK (running it on a Lenovo Thinkpad laptop)
grep the file of interest results in "No such file or directory"
I tried to find the path of the file (readlink, realpath) but guess the commands were not applicable here?
Also tried /home/A/file or /home/A/desktop/file but it is clear that my random guess fails.
From windows, the file should be in
C:/Users/non_admin/desktop/folder/file
What would be the right path of the file to grep the string using cygwin ?
You can use /cygdrive to access the Windows filesystem. In your case, try
grep foo /cygdrive/c/Users/non_admin/Desktop/folder/file
From windows, you can get the correct file path from the context menu item Copy as path into the copy/paste buffer.
In Cygwin mintty, use
FilePath=<paste>
where <paste> means to use paste from mintty's context menu to make a variable with the value of that path.
Then use
grep <string> $(cygpath -u "$FilePath")
to search the file. The "'s are in case the file name contains spaces.
HTH
Consider following:
$ cd /home/mydir
$ jupyter notebook --port=8888
In plain English, I am running jupyter server from /home/mydir directory.
Is there a simple way to get this directory from within a notebook regardless if it's a R notebook or a Python notebook or whatever? Maybe there is some magic command or variable?
NOTE: getwd() is not an answer as it returns directory of a current notebook but not the jupyter server root.
I have a similar problem and found your post, although I don't see a viable solution yet. Eventually I did found a solution, although it works only because I only care about Linux and I only care about Python. The solution is this magic line:
J_ROOT = os.readlink('/proc/%s/cwd' % os.environ['JPY_PARENT_PID'])
(I put it in a module in my PYTHONPATH so that I can easily use it in any Python notebook.) See if it is good for you.
Remember that your iPtyhon is just a Python module, so you can execute any valid Python code in a cell. So, if you started your notebook and haven't executed any directory changes in your code, you should be able to retrieve your cwd with the following in a cell:
import os
os.getcwd()
But furthermore, you can execute shell commands in cells, so you can retrieve other information in the cell. For example:
!which jupyter
should give you the path to your jupyter executable.
Which then leads you to running something like:
!jupyter --paths
which should give you something similar to:
config:
/Users/yourdir/.jupyter
/usr/local/etc/jupyter
/etc/jupyter
data:
/Users/yourdir/Library/Jupyter
/usr/local/share/jupyter
/usr/share/jupyter
runtime:
/Users/yourdir/Library/Jupyter/runtime
Frankly I'm surprised that all this time later there is still no built-in way to do this. I have used Isaac To's solution on Linux but recently had to make a jupyter notebook portable to Windows as well. Simply using os.getcwd() is fragile because a cell using it to set your JUPYTER_ROOT_DIRECTORY can potentially be called again, after you have changed your working directory.
Here is what I came up with:
try:
JUPYTER_ROOT_DIRECTORY
except NameError:
JUPYTER_ROOT_DIRECTORY = os.getcwd()
I put it in one of the first couple cells with the initial import statements. If the cell gets called again, it will not re-set the variable value because the variable exists and does not throw an exception.
It should be noted that unlike Isaac To's solution it sets the value to the directory the current .ipynb was run from, which is not necessarily the same directory as the top-level dir the user can access in the left hand file pane.
My suggestion is to use an intuitive approach.
Create a new folder within the Jupyter environment with a very unique name, for example, T246813579.
You can now locate the Jupyter working path by searching in your file explorer. For example, you can use the Windows Explorer in order to locate your new folder.
The expected result should look something like this:
C:\Users\my_user_name\JupyterHome\T246813579
The answer from #Isaac works well for Linux, but not all systems have /proc. For a solution that works on macOS and Linux, we can use shell commands, taking advantage of the ! shell assignment syntax in Jupyter:
import os
JPY_ROOT = ! lsof -a -p {os.environ['JPY_PARENT_PID']} -d cwd -F n | tail -1 | cut -c 2-
JPY_ROOT = JPY_ROOT[0]
print(JPY_ROOT) # prints Jupyter's dir
Explanation:
Get the process ID (pid) of the current jupyter instance with os.environ['JPY_PARENT_PID']
Call lsof to list the process's open files, keeping only the current working dir (cwd)
Parse the output of lsof using tail and cut to keep just the directory name we want
The ! command returns a list, here having only one element
Alternate Version
To save the os import, we could also use shell commands to get the PID. We could also do the subsequent string wrangling in python, rather than calling tail and cut from the shell, as:
JPY_ROOT = ! lsof -a -p $(printenv | grep JPY_PARENT_PID | cut -d '=' -f 2) -d cwd -F n
JPY_ROOT = JPY_ROOT[2][1:]
I'm trying to wrap my head around this: on Windows, I use cmder (a wrapper around ConEmu) which improves on the bare cmd.exe experience (a lot) but can also host other shells like PowerShell or Git Bash. I'd like to go more "unix-y" but still well integrated with my Windows tools. Git Bash strikes the right balance for me: I can do things like rm -rf node_modules but still run my Windows commands fine.
It's easy to get Git Bash going inside cmder, however, I'd like to replace the shell with zhs, mainly to get the super-useful "up arrow respects the current prefix" feature (I write git, press the up arrow and only get suggestions on the recent Git commands).
The question is, who will handle the up arrow? Will it be ConEmu and do Windows-y stuff (cycling through all the commands) or will it fall down to zsh and the cycling will be implemented by it? How does this work?
Related: ConEmu: possible to change the up arrow behavior?
ConEmu's disclaimer states
ConEmu is not a shell, so it does not provide "shell features" like remote access, tab-completion, command history and others.
Only the shell itself knows when user types a command and only the shell may store executed commands history. Of course, only the shell may process Up/Down/Tab keys to "browse" stored history of commands.
cmder is a bundle of tools including clink, which integrates into cmd.exe and process cmd's prompt internally. So, in cmder by default Up/Down/Tab arrows are processed by clink.
More info is here: http://conemu.github.io/en/TabCompletion.html
I have a setup I'm pretty happy with for sharing my configuration files between machines, but I find that I often want to search back in zsh (Ctrl + R) and I can't remember which machine I typed the command on. Ideally I'd like this to search a canonical de-duped list of previous commands from any of my machines. Given that I sometimes work on these machines concurrently and without a network connection, what's a sensible way of merging history files and keeping everything in sync?
I wrote this plugin for oh-my-zsh:
An Oh My Zsh plugin for GPG encrypted, Internet synchronized Zsh history using Git
https://github.com/wulfgarpro/history-sync
Hmm, I guess you could identify your accounts somehow... then you could do the following:
modify your .zshrc to catenate the history of the OTHER accounts from dropbox or SCM with the current history IF this is the first zsh launched on the current computer
then sort the entries with -n (sort by timestamp)
I guess zsh would remove the duplicates if you have setopt HIST_SAVE_NO_DUPS
Then you need to trap shell exit, and copy the existing history to the dropbox/SCM/whatever shared place.
You could have a NFS mount point for the involved machines with the .zsh_history in it. Each machine would need the HISTFILE env var set to that file path in the NFS.
HISTFILE env var is compulsory, since ZSH does not accept a symlink, and it would be replaced by a file using the last version of the symlink target.
I have not tested what is said above, since my setup is between VM's using OSX and Parallels shared folders. Hence, with NFS the integrity (order?) of the file could be something to consider, also VS the Dropbox solution.
Not sure, something like https://gist.github.com/elim/f77e3e9f06b6f8a5e788 could be used to fix versions to be merged...
I use the command below:
ssh username#example.com cat ~/.zsh/.zhistory | cat ~/.zsh/.zhistory - | sort | uniq | tee ~/.zsh/.zhistory | ssh username#example.com cat \> ~/.zsh/.zhistory
I just started using Zsh lately for some of the integrated support in the shell prompt for my Git status etc.
When I type in:
ruby -v
to confirm the version of ruby I'm running, Zsh asks if I want to change the command to _ruby. Well after saying no at the prompt and the command completing as expected I continue to get the question at the prompt after confirming my command is correct.
I'm assuming there is a completion file or something of the sort.
Thanks
Update:
The shell is no longer trying to complete _ruby, it stopped responding after closing the shell a few times some how.
I tried to clean the file up several times but there is a "opts" variable that is 50 or more lines long and the lines are all ran together, some lines more than 150 characters. Maybe I could email an attachment to you if you still want to see it.
I sincerely apologize for the messy post.
This is command autocorrection, activated by the correct option. It has nothing to do with completion. You're seeing _ruby because zsh thinks there is no ruby command and it offers _ruby as the nearest existing match.
If you've just installed ruby, it's possible that zsh has memorized the list of available command earlier, and it won't always try to see if the command has appeared in between. In that case, run hash -rf. Future zsh sessions won't have this problem since the ruby command already existed when they started.
Sometimes, when you change your PATH, zsh forgets some hashed commands. The option hash_listall helps against this. As above, if you can force zsh to refresh its command cache with hash -rf.
You could make an alias:
alias ruby='nocorrect ruby'
It's what I did when zsh kept asking me if I meant .meteor when I typed meteor because auto-correct is still useful from time to time.
I find the autocorrect feature can get annoying at times. So I do in my ~/.zshrc,
DISABLE_CORRECTION="true"
I had the same problem even when the command is not installed.
I can solve it using the CORRECT_IGNORE variable in my .zshrc
# OPTs to enable
setopt HASH_LIST_ALL
setopt CORRECT
# Zsh variable to determine what to ignore,
# in this case everything starting with _ or .
CORRECT_IGNORE="[_|.]*"
I hope it helps to you or anyone with this issue
Sometime ago after an update, I got command auto-correction enabled which I don't want. If the same happened to you and you want to revert it, in the ~/.zshrc file you'll have make it:
# Uncomment the following line to enable command auto-correction.
ENABLE_CORRECTION="false"
or comment it as per bellow:
# Uncomment the following line to enable command auto-correction.
# ENABLE_CORRECTION="true"
Just a note, on my zsh (version 5.7.1 on macOS), the DISABLE_CORRECTION didn't work.
I saw in my .zshrc file the following two lines, which I then commented out
setopt CORRECT
setopt CORRECT_ALL
That did it for me.