I've got this neat little function to open man pages in the Preview.app in my bash profile
pman() {
man -t $# | open -f -a /Applications/Preview.app
}
and I want to use it in my zshrc but it doesn't work does anybody know how to fix it? Preview.app still opens but it ask which file to preview and not like in bash which opens the man page.
Thanks in advance
Related
I recently installed MSYS2 with Emacs (64-bit) and am currently calling that Emacs from a Windows shortcut. It works fine, exactly like if I had downloaded the Emacs executable for Windows and unzipped it somewhere. Which is to say, it picks up all of my Windows environment variables and such.
For various reasons, I would prefer to run Emacs from an MSYS2 bash shell and use the environment variables in that shell. As it stands, I can open an MSYS2 MINGW64 shell, type emacs on the command line, and everything works the way I want it to.
Now I would like to package the whole thing up into either a one-liner I can stuff into to a Windows shortcut or a script I can call from a Windows shortcut. With the help of this post, I came up with the following:
C:\msys64\bin\mintty.exe /bin/env MSYSTEM=MINGW64 /bin/bash -l -c /mingw64/bin/emacs
This successfully opens Emacs, but fails to load the .bashrc file that I source in .bash_profile in the usual manner:
if [ -f "${HOME}/.bashrc" ] ; then
source "${HOME}/.bashrc"
fi
I define a function in .bashrc that I call in .bash_profile, so this is kind of important. It did not take much effort to realize that the problem is that HOME is not defined, so .bashrc is simply not found. However, if I define HOME like so:
C:\msys64\bin\mintty.exe /bin/env HOME=/home/alanhr MSYSTEM=MINGW64 /bin/bash -l -c /mingw64/bin/emacs
I get exactly the same result: .bashrc is not found and my function is not executed. Here's where it gets weird. If I simply leave off the call to emacs like so:
C:\msys64\bin\mintty.exe /bin/env HOME=/home/alanhr MSYSTEM=MINGW64 /bin/bash -l
I get a bash shell where .bashrc has been loaded correctly and my function is correctly executed. I can type emacs on the command line and have it function exactly as I want it to.
This feels like a classic case of missing something that is right under my nose, but I have read the bash man page to no avail. Does anyone have any idea how I can make this work?
It is the -i option to load .bashrc. The following works for me:
C:\msys64\usr\bin\mintty.exe -w hide /bin/env MSYSTEM=MINGW64 /bin/bash -l -i -c /mingw64/bin/emacs
I have one script like
history
test.sh file in that I just put history
Now I run sh test.sh
Then it gives error like : history: command not found
Thanks In Advance
history is a command of the shell, so it should not look for it as if it were an external command (like ls)
I made a quick test and did not experience your problem, although I needed to use
set -o history
in order for history to display.
Can you provide further details?
I am not exactly a pro at BASH Scripting, but I can get by with the basics. I use MRXVT with Cygwin on my windows box (MRXVT is an RXVT Terminal with tabs. RXVT is a Standard Cygwin terminal, but with enhanced features). I found a command to change the tab names for MRXVT:
echo -ne "\e]62;New tab title\a"
It works like a charm. I'm not, however, interested in A)Changing it manually or B)Changing it to a static String
I use a lot of SSH. I'd like the tab title to be username#host[current directory] at any given time.
I'm not sure if I'm supposed to use a trap for this. Frankly, I don't understand how traps work. I guess I could create an ssh alias that pulls the first argument of the ssh command and sets the tab title to that...This would be sufficient, but not preferred.
Do you guys have any ideas?
Found an answer. added
trap 'echo -ne "\e]62;mrxvt: $USER#${HOSTNAME}\007"' DEBUG
to the very end of my .bashrc. I decided I didn't like having the path in my tabs (or titlebar for that matter). Also, I had to add "mrxvt: " to the beginning of the string because of an AHK script that I wrote; it wouldn't work properly otherwise. The full answer to this is:
trap 'echo -ne "\e]62;$USER#${HOSTNAME}[${pwd}]\007"' DEBUG
Again, just add that line to the end of your .bashrc, and you're good to go.
Hope this helps somebody else :)
I wrote a bash script that fetches lyrics from a website. The script is here --> http://scrippets.wordpress.com/2011/02/01/fetching-lyrics-of-songs-from-the-terminal/ (the indentations in the script are correct unlike how it looks on the blog)
This script works perfectly well when executed from the terminal. Now i created a custom keyboard shortcut using compiz commands, that executes the following command when the right key combination is pressed :
gnome-terminal --working-directory="/home/tapan/sandbox/bash/" --window-with-profile=lyrics -e "/home/tapan/sandbox/bash/lyrics.sh" -t "`rhythmbox-client --print-playing`"
I created a new profile called "lyrics" to give the terminal that opens up a custom look. When i open up a terminal with this profile and run the script, it works perfectly fine again. However, when i use the keyboard shortcut to run the custom command, i get the following error:
Pink Floyd - Is There Anybody Out There?
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
cat: 3.txt: No such file or directory
I cannot figure out whats wrong. I mean if it works perfectly well in the terminal normally, why shouldn't this work? Any suggestions?
PS: The script i have written is pretty elementary and noobish, so any suggestions to improve it are also welcome in the comments :)
EDIT: The output has changed a little, now it just shows the name of the song playing and nothing else. Though sometimes it still shows the wget error.
EDIT2: When i run that gnome terminal command from a terminal, it works. The problem is only when running it with the keyboard shortcut using compiz commands or if i use the run dialog (the alt+f2 one).
The two wget commands should probably have the url variables in double quotes, for example: wget -q -U Mozilla -O 1.txt $link should be wget -q -U Mozilla -O 1.txt "$link"
You need to uriencode your song title so that special characters like '?', '&', '%', and '+' are not passed literally in your URL.
name3=${name2//\?/%3F}
searchq=${name3// /+}
will handle the ?'s. I don't know of a more general solution in bash without resorting to one-line Perl or Python scripts.
I tried this just now:
grep -RlI "id=\"kw\"" * | xargs vim
That gave me 16 results. It opened the first result in Vim. I made my very first edit and hit :q since I didn't know the shortcut to jump to the next file.
It threw me back to the console ( I am SSHed in to a server ). My console is messed up now. Anything I type I can't see, and anytime I hit enter it seems like it processes the command but the display/view is screwed up so
[meder#linode] is tabbed in on my console, at least halfway. reset does nothing since it seems to have messed up my real console.
Can anyone offer a solution that doesn't have this same downside? Or can anyone provide an explanation for why :qing out of the very first file messed up my console?
Background information: My PC is Debian Ubuntu, I am SSHed into a RHEL box. The files I opened were text/ascii files phtml/php files and not some weird binary files with crazy characters in them.
Here's a screenshot of what happened
EDIT #1: I just typed reset again and it seemed to work. The first reset did not work I think because somehow the console inserted some whitespaceish character inside it? Anyways, I would like an explanation for this weird behaviour.
Try:
vim -o `grep -RlI "id=\"kw\"" * `
From the man page for xargs:
Undefined behavior may occur if utility reads from the standard input.
That line isn't in the Linux man page but it is present on my Mac. If you want to run a program that you intend to read standard input, the usual linux version of xargs will need an argument to read its input from a file:
OPTIONS
--arg-file=file, -a file
Read items from file instead of standard input.
If you use this option, stdin remains unchanged
when commands are run. Otherwise, stdin is
redirected from /dev/null.
Vim is intended to run with both standard input and standard output connected to real (a very rare case these days) or pseudo tty devices. Wierd things will happen if you upset this arrangement.
The fundamental problem with your command was that, with standard input redirected to the pipe, xargs had no way to run a vim with a "normal" standard input. So the vim mode changes and command input were not what you expected.
You can probably fix this by typing a return, a tilde, and a period. This will force your ssh session closed from your end, you can then ssh in again, and run "ps" to check for anything left hung in the background that you should kill(1).
You can use :next or :n to get to the next file to edit. You can also use vim -o to open up all the matching files in different windows in Vim.
Not sure why your console is messed up though. I tried using your command and my console was fine.
Console options are set by stty, so you may want to save its options to a bash variable and restore them after vim exits, like this:
function vim()
{
STTYOPTS="$(stty --save)"
vim "$#"
stty "${STTYOPTS}"
}
But it is probably the better way to use zsh for this task: if you put the only line ttyctl -f into your ~/.zshrc, then zsh will automatically restore terminal options after program exits. ttyctl is a zsh builtin, so you cannot use it from bash.
Other folks covered what happened and what to do about it. As to why, the answer to that probably lies in what input Vim received from the xargs command and tried to execute as if that input came from a terminal. I don't know how to talk terminal, but you can imagine that Vim got some strange commands that crashed it or told it to quit. Similarly unpredictable things happen when you cat a binary file.
Anway, I have another idea. Have you tried using vimgrep to browse a list of files matching a pattern?
:vimgrep /id="kw"/ *
:copen
This greps for id="kw" in all files in the current directory. :copen opens up a window with a list of matches. You can browse that list, clicking enter to jump to a file position.
For more information, see
:help grep
:help :vimgrep
:help :copen
:help quickfix
If you really need that -I option, see
:help :grep
:help 'grepprg'
See also: Vim: Warning: Input is not from a terminal
Try to use ... | xargs sh -c '...' and then read from the controlling terminal device /dev/tty.
echo ~/.profile ~/.bashrc | xargs sh -c 'vim "$#" </dev/tty' dummy_script_name
# based on a tip by Laszlo Ersek on http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2010-03/msg00051.html
#find . -maxdepth 1 -type f | xargs sh -c 'rm -i "$#" </dev/tty' dummy_script_name