I can do this in bash
vim `ls | percol`
while corresponding command in fish
vim (ls | percol)
just opened an empty file, (ls | percol) seemed to be ignored. what am I missing?
This was a bug in old fish versions that has been fixed in 2.6.0 (released June 2017).
Related
I'm using using VSCode Remote SSH from my laptop (Linux) to work on projects that resides on a Linux host.
If I open an internal terminal in VSCode I can open files from the host by doing code some_file.txt. I frequently want to be able to do the same from terminals that are not originating from VSCode.
Is there anyway to open files in the VSCode-server while connected to a standard (Non VSCode internal) terminal?
From another StackOverflow answer, I learned that if you open an integrated terminal and find the VSCODE_IPC_HOOK_CLI environment variable, and set it to the same value in the non-integrated terminal, then run code from the code server install directory ~/.vscode-server, it will work. That article didn't mention that you can have more than one install in the ~/.vscode-server directory. The current install can be extracted from the VSCODE_GIT_ASKPASS_MODE variable, it looks like this:
$ echo $VSCODE_GIT_ASKPASS_NODE
/home/<user>/.vscode-server/bin/054a9295330880ed74ceaedda236253b4f39a335/node
Just chop off the node and add bin, and so run something like
$ /home/<user>/.vscode-server/bin/054a9295330880ed74ceaedda236253b4f39a335/bin/code myfile.txt
Edit:
Here is a small script that will connect the terminal to the latest created vscode window.
❯ cat ~/.local/bin/connect_vscode.sh
export PATH="${HOME}/.vscode-server/bin/$(ls -t1 ${HOME}/.vscode-server/bin | head -n 1)/bin:${PATH}"
export VSCODE_IPC_HOOK_CLI="$(ls -t1 /run/user/$(id -u)/vscode-ipc-* | head -n 1)"
# Tell tmux to set these variables for new windows/panes.
# Remove if you don't use tmux
tmux setenv PATH "$PATH"
tmux setenv VSCODE_IPC_HOOK_CLI "$VSCODE_IPC_HOOK_CLI"
None of the answers on this thread worked for me (due to more recent versions of VS-Code changing it's internal paths and I'm running a preview version).
I'm linking this similar/identical question+my solution:
VSCode Remote SSH doesn't open file from terminal
Hope it helps. 😉
C. R. Oldham's answer covers the technical detail of why/how.
If you want a 1-liner that works as an alias in your ~/.bash_profile:
# Open file in most recently-connected remote VSCode session.
alias code=$'VSCODE_IPC_HOOK_CLI=/run/user/`id -u`/$(ls -lt /run/user/`id -u`/ | egrep \.sock$ | head -1 | awk \'END {print $NF}\') `ls -lt ~/.vscode-server/bin/** | fgrep bin/remote-cli/code | head -1 | awk \'END {print $NF}\'`'
I have the following sed code that works in RH6 and sed 4.2.1
>> echo "SUSE Linux Enterprise Server 11 ( x86_64 ) VERSION = 11 PATCHLEVEL = 2" | sed s/.*VERSION\ =\ //
11 PATCHLEVEL = 2
>> sed --version
GNU sed version 4.2.1
but it fails at SUSE 11 and sed 4.1.5
>> echo "SUSE Linux Enterprise Server 11 ( x86_64 ) VERSION = 11 PATCHLEVEL = 2" | sed s/.*VERSION\ =\ //
sed: No match.
>> sed --version
GNU sed version 4.1.5
I found the following code works differently in the two versions. sed 4.1.5 in SUSE cannot match anything.
echo ab | sed s/.*//
Is it a known issue of sed? and does it have a solution?
Since you didn't quote the asterisk, your shell is trying to glob it. On one of your systems this globbing fails and the original string is returned. On your other system it matches something and your substitution regex is destroyed. Always quote arguments that the shell might consider "special".
I found sed 4.1.5 needs single quotes to make things work. The following works.
echo ab | sed 's/.*//'
But the sed 4.2.1 does not need this.
I'm trying to copy using the command provided in here. That is,
alias | sed -E "s/^alias ([^=]+)='(.*)'$/alias \1 \2 \$*/g; s/'\\\''/'/g;" >~/.emacs.d/eshell/alias
This worked with Bash, I was using Emacs-Starter-Kit; but not working with Zsh -- not working means it copied things but to no effect.
[As a side note]
It seems like, I don't have few Eshell default variables i.e. eshell-read-aliases-list, and eshell-aliases-file. So, I even don't know where should my Eshell alias file reside.
Got it working after setting
(setq eshell-directory-name (expand-file-name "./" (expand-file-name "eshell" prelude-personal-dir)))
in post.el (my personal .el file for post-processing) under prelude/personal
... and modified the given bash command to
alias | awk '{print "alias "$0}' | sed -E "s/^alias ([^=]+)='(.*)'$/alias \1 \2 \$*/g; s/'\\\''/'/g;" > ~/.emacs.d/personal/eshell/alias
... and appended that to .zshrc.
Found that alias command, in zsh, prints aliases without prefix alias<space>, unlike bash. Therefore this part
| awk '{print "alias "$0}'
I need to rename all files whose name contains the substring 200at and substitute it with 200_at.
In Ubuntu, I would do:
find . -type f -name '*200at*' -exec rename -n 's/200at/200_at/' {} \;
In CentOS (version 5.9) it doesn't work. The command rename doesn't seem to support perl expressions and the above command does nothing at all.
Any ideas for an alternative?
In my experience with CentOS, we always used the mv (move) command for renaming things. ie:
mv 200at ./200_at
hope that works as your alternative.
I am having problems with the greps in Emacs.
a) grep doesnt seem to understand the .[ch] for searching .c and .h files. This is a default option provided by Emacs with the lgrep command. The example is searching for the word "global" in .c/.h files.
grep -i -nH "global" *.[ch]
grep: *.[ch]: No such file or directory
Grep exited abnormally with code 2 at Mon Feb 16 19:34:36
Is this format not valid?
b) Using rgrep I get the following error:
find . "(" -path "*/CVS" -o -path "*/.svn" -o -path "*/{arch}" -o -path "*/.hg" -o -path "*/_darcs" -o -path "*/.git" -o -path "*/.bzr" ")" -prune -o -type f "(" -iname "*.[ch]" ")" -print0 | xargs -0 -e grep -i -nH "global"
FIND: Wrong parameter format
Grep finished (matches found) at Mon Feb 16 19:37:10
I am using Emacs 22.3.1 on Windows XP with the GNU W32 Utils (grep, find, xargs etc.). Grep v2.5.3 and find v4.2.20.
What am I missing?
UPDATE:
Too bad one can't accept multiple answers...since the solution to my problems are spread out.
grep -i -nH "global" *.c *.h
This solves the first problem. Thanks luapyad!
(setq find-program "c:\\path\\to\\gnuw32\\find.exe")
emacs was indeed using the Windows find.exe. Forcing the gnu32 find fixed the second problem. Thanks scottfrazer.
However, I still like ack best.
I found out that using:
(setq find-program "\"C:/path/to/GnuWin32/bin/find.exe\"")
(setq grep-program "\"C:/path/to/GnuWin32/bin/grep.exe\"")
Works better in windows, since you could have a space laying around the path and will screw up eventually.
Notice I used the two programs in my .emacs file.
Hope it's of some help to some other programmer in need ;)
Well, there is always Ack and Ack.el
For a) it looks like there are simply no .c or .h files in the current directory.
For b) Windows is trying to use its own find instead of the one from the GNU W32 Utils. Try:
(setq find-program "c:\\path\\to\\gnuw32\\find.exe")
Adam Rosenfield comment is worth expanding into an answer:
grep -r --include=\*.[ch] --exclude=\*{CVS,.svn,arch} -i -nH
To make the example given in this question work, use this:
grep -i -nH --include=\*.[ch] "global" *
It is also helpful to set the variable grep-command providing defaults to M-x grep:
(setq grep-command "grep -i -nH --include=\*.[ch] ")
Also here are some other useful command line parameters to grep:
-n print the line number
-s suppress error messages
-r recursive
I think the general problem is the windows cmd "shell" behaves very differently to a unix shell in respect to filename expansion regexps and wildcards.
To answer your (a) above try using:
grep -i -nH "global" *.c *.h
(You will still get an "invalid argument" if no *.c's or *.h's exist).
Or you can use command line option --include=\*.[ch] to make windows grep do "proper" filename pattern matching (see grep --help for other options)
I usually just use M-x grep and alter the command line args when prompted if I need to. But I just tried running M-x lgrep and got the same thing as you. It simply means that no files match *.[ch] in the current directory. You can customize the default options to include -r and search recursively through child directories as well:
M-x customize-group RET grep RET
Search for lgrep in that buffer to find/edit the Grep Template.
As far as M-x rgrep goes, I suspect it has something to do with the Windows version of find not liking the default options. That command works fine for me on Linux. Search for rgrep in that same customize buffer and tweak those options until the Windows find is happy.
Sorry I can't be more help with the Windows options, but I'm not familiar with them.