I often find myself taking a lot of time to navigate through my filesystem when using the linux shell. This generally occurs because the autocompletion of bash only works if you provide the start of the file/dirname. What I often end up in is a lot of 'ls' with 'grep' commands, finally doing a 'cd'.
When you use a GUI based filebrowser (like Nautilus) you can type any part of a file/dirname and it will have matches that it jumps to directly. This makes it a lot easier and faster to navigate.
I wonder if anybody knows any great tools that helps with this problem. I know of the existence of Midnight Commander, though I never really used it for real and I couldn't figure out a direct solution for my problem the first couple of times I tried it. Also it seems not suitable because I want to have my shell's current working directory to be changed so I can do stuff there, instead of being stuck in an external program like Midnight Commander.
Try autojmp
https://github.com/joelthelion/autojump
And following article provides another solution
http://jeroenjanssens.com/2013/08/16/quickly-navigate-your-filesystem-from-the-command-line.html
You can first use the autocd or autopushd in zsh. You would just have to type the directory you want to go to, without the hassle of typing cd or pushd everytime.
You also have the globing possibility. For example, if I got those file in a directory:
1-a.tar
1-b.tar
c.tar
I can just type
*a.tar
without caring about the beginning of the file.
As a last solution you can always use an alias to the find command with a personalized option.
Related
I want to run following Linux command which opens the document with application registered with the system:
xdg-open mydocument.pdf
I see that many commands for this are available: run, run*, capture, shell, execute, system* etc.
from: http://wiki.call-cc.org/eggref/4/shell and https://wiki.call-cc.org/man/4/Unit%20utils
I also need the result of the command (ran successfully or not) from this.
Following (system without *), although not listed, also seem to work well:
(define result (system "xdg-open mydocument.pdf"))
Which of these will be the safest way to run system commands as above?
If the name of the document is hardcoded, it doesn't matter much what you use. If the file name is user-supplied, you must use qs to quote the arguments if you're relying on a string-based API like system's. It might be easier to pass arguments separately using process.
I don't know the shell egg very well, but if you want to get really fancy with shell calls, the scsh-process egg is a very nice alternative (full disclosure: I'm its author).
I have a program, let's call it exampleProg, in my /opt directory, and I want to run it from any directory, rather than just:
/opt/radFolder/exampleProg
This should be a simple task, I've done it several times before on different computers. I've searched around, and found instructions ranging from:
edit .bash
edit .bashrc
edit .profile (Another stackoverflow answer said that, while this worked at one time, it no longer functions.)
edit /etc/environment/
with PATH="$HOME/bin:$PATH:/opt/radFolder/:" or just adding the /opt/radFolder bit.
Yet none of them seem to work. The problem that I'm running into is that there doesn't seem to be a yet there doesn't seem to be a universally agreed-upon solution. I've tried so many that I think one of my changes has prevented the appropriate one from taking effect. Would someone help me put this to rest once and for all? Many thanks in advance.
I'm running ubuntu 14.04 LTS x64.
First, understand that writing things to those files does not mean everything is instantaneously, and globally, changed. In fact, nothing is changed until the file is sourced (via . or source), and even then, the environment changes apply only to the current shell (and subsequent created children, if export is used).
INVOCATION, near the top of man bash, spells out which files are automatically sourced when. To summarize:
~/.bashrc is read for new non-login, interactive shells, e.g., when you open a GUI terminal. On many systems, this file by default in turn sources /etc/bashrc.
/etc/profile, ~/.bash_profile, and ~/.profile are read by interactive login shells.
Adding to ~/.bashrc should be effective, but it will only work for subsequently invoked, interactive, non-login shells (and their children, if $PATH is exported). However, since it's prone to being sourced repeatedly, using it to add to an existing variable (as with $PATH) can produce repeated concatenations (see here).
An issue with the second category, .profile, is that if you use a GUI login, the display manager may not source it, but it logs you in, meaning, you never invoke a login shell and hence none of those is ever sourced. If this is the case, sourcing them from ~/.xsession should work (this has a system wide correlate in /etc/X11).
I can scroll trough bash output using shift+pgup/pgdown.
But lets say, some command outputted lot of text, I have to pageup few times to go to beginning of output of this command.
Can I just simply do this by some shortcut? Something that simply allows me to scroll between previous commands (not history!), seeing their output.
You could try piping the output into less:
someCommand | less
less will allow you to search and scroll through the output text pretty easily.
once in less you can just type % to jump back to the top of the page. Essentially that means jump to 0% of the page. There are also a bunch of extra commands on the page I linked to above.
Another option is to use screen and use backward search (beware: read the Overview first, especially the part about the C-a prefix) to e.g. search for some specific characters in your prompt (like your username).
The scroll back history in Unix shells is a shell specific functionality, meaning that it is up to the specific shell (xterm, rxvt, text console, etc) to handle it. The functionality you request would require the shell to identify the individual program runs, to know where to scroll to. Scanning text is not technically hard per se, but as prompts and command display can differ due to user settings it can be hard to make it work generally good. Some communication between the shell and the terminal could make it better.
There sure are some nice fancy terminal programs doing things like this, to for example show syntax help when writing commands, but for your case I agree with previous answer, that piping commands to less is a good way to isolate the output. It might be a bit cumbersome first, as it requires you to think about it first, and not just go back in history, but if you learn the shell better and learn to use the command history it will probably work fine. I recommend you to, if you haven't already. What I mean is ctrl-r etc. More described for example here:
http://www.catonmat.net/blog/the-definitive-guide-to-bash-command-line-history/
Problem
I'm writing a set of scripts to help with automated batch job execution on a cluster.
The specific thing I have is a $OUTPUT_DIR, and an arbitrary $COMMAND.
I would like to execute the $COMMAND such that its output ends up in $OUTPUT_DIR.
For example, if COMMAND='cp ./foo ./bar; mv ./bar ./baz', I would like to run it such that the end result is equivalent to cp ./foo ./$OUTPUT_DIR/baz.
Ideally, the solution would look something like eval PWD="./$OUTPUT_DIR" $COMMAND, but that doesn't work.
Known solutions
[And their problems]
Editing $COMMAND: In most cases the command will be a script, or a compiled C or FORTRAN executable. Changing the internals of these isn't an option.
unionfs, aufs, etc.: While this is basically perfect, users running this won't have root, and causing thousands+ of arbitrary mounts seems like a questionable choice.
copying/ hard/soft links: This might be the solution I will have to use: some variety of actually duplicating the entire content of ./ into ./$OUTPUT_DIR
cd $OUTPUT_DIR; ../$COMMAND : Fails if $COMMAND ever reads files
pipes : only works if $COMMAND doesn't directly work with files; which it usually does
Is there another solution that I'm missing, or is this request actually impossible?
[EDIT:]Chosen Solution
I'm going to go with something where each object in the directory is symbolic-linked into the output directory, and the command is then run from there.
This has the downside of creating a lot of symbolic links, but it shouldn't be too bad.
You can't solve this without making some assumptions about the interface of $COMMAND. There is no single definition of what "output ends up in $OUTPUT_DIR" means. For one program this may be some files, but another program might just print something to stdout and yet another might try sending some data over the internet using some protocol or display something in a GUI and there isn't an obvious way of mapping all of these to "output goes to $OUTPUT_DIR".
So, you need to invent some assumptions and require any $COMMAND implementation to follow them. Then, it may get as simple as requesting that the command accept a parameter such as --target=<DIR>. If your command was some simple command, you would have to create a wrapper script around it to translate that parameter into what the app accepts. cp, mv and a few more utils already accept the parameter --target, so that may be a good starting point.
You cannot set the output directory, you can only set the working directory.
The problem is, once you set the working directory, other references are going to be invalid. For example in your code foo:
cp ./foo ./bar
If you have a specific command, there are workarounds (creating a script that alters arguments, prepending the directory to specific arguments), but in general this is not possible.
I have some directories with a number of "hidden" files. One example of this is I'm in a source controlled sandbox and some of the files have not been checked out yet.
When I hit TAB, I'd like the option of seeing these files.
A similar question has been asked before: CVS Tab completion for modules under linux
The answers to that question summarize to: "Ubuntu's got that built in".
I don't have the option of switching to Ubuntu, but surely I can use the same mechanisms.
how can I hook into the TAB-completion feature of tcsh to add additional file Support for CVS, SVN and BitKeeper would all be useful.
More important than support for a specific source control system is the ability to control the returned list myself.
An acceptable solution would also be to use a key-binding other than TAB. (ctrl- perhaps)
From the manpage:
the complete builtin command can be used to tell the shell how to complete words other than filenames, commands and variables
might get you started
I do not know how to program in tcsh. But if you can, then you could look at the file named "bash_completion" from the archive (find the download link here.)
On line 1673 begins CVS completion code - and this might be portable to csh if you are familiar with the differences between bash/tcsh.
On my ubuntu machine, there is also a section for SVN completion (in /etc/bash_completion) that doesn't seem to be present in the maintainer's archive.
That's not Ubuntu-specific behavior, it's the bash-completion project.
You could use that, if you can switch from tcsh to bash.