Bash Command Line – Capture and Use Last or Nth Line in stdout

bashcommand line

Query

I use Bash. When I'm looking for files, often I'll do the following:

find -name stackexchange.hs

And often the results will look like:

/youre/the/man/now/dog/stackexchange.hs
/you/are/no/longer/the/dog/dog/stackexchange.hs
/this/is/the/file/i/want/stackexchange.hs

Then I'll want to do one of the following:

Option 1: Open the last item in the list of results in vim.
Option 2: Open the Nth item in the list of results in vim.

Currently, I cut-and-paste with the mouse. Which brings me to my question:

Is there an easy, one-liner to accomplish options 1&2? Note that this is occurring after the find command.
Is there a way to capture N-lines from stdout in some kind of bash vector/array?

Ideal usage

$ find -name am_i_really_all_alone.txt
./borges/library/you_are_not_alone.txt
./borges/library/am_i_really_all_alone.txt
$ vim (N)

(syntax and semantics may differ, but you get the point)

Similaria

There seem to be several similar questions. Here are my perceived differences (I am open to enlightenment):

"Open File Found with find Command" focuses on creating a one-line to pipe a file name from find into vim (or whatever). In my case, I want to find first, pipe later (so to speak). My capture / usage happens strictly after.
"Reuse Last Output From Command Lind" seems bang-on, but seems to simply repeat the command and doesn't speak to capturing the Nth line of output. Quite frankly, it scares me.
"Capture Multi-Line Output of a Bash Builtin" is close, but not quite there.
"What is the exact difference between terminal, shell, tty, console, etc." this one is really just a good read.

Thank you for your help! Having used *nix/BSD when I was a teenager in the 90s and getting scared away by calling my burnout, acid-head neighbour to help me install drivers for my plug-and-play sound card, I'm relieved to discuss command-line minutiae with (perceivably) less frightening individuals. It feels good to be back.

Best Answer

Here is a potential solution to your issue that should be reasonably (but not perfectly) safe in the presence of funky file names (doesn't handle filenames with linefeeds in them - probably fixable, but there might be other problems lurking).

Two functions, the first one runs find with the parameters you pass it, saves the output in an array, and displays them. The second is just a helper to access that array.

myfind() {
  IFS=$'\n' __last_find_result=($(find "$@"));
  printf "%s\n" "${__last_find_result[@]}";
}
myget() {
  echo "${__last_find_result[$1]}";
}

Use case:

$ myfind . -name "c*"
./a b/c d
./.git/config
./.git/hooks/commit-msg.sample
$ vim "$(myget 0)"
# This opens the "./a b/c d" file.
$ vim "$(myget 2)"
# This opens ".git/hooks/commit-msg.sample"

Quotes not required around the $(myget index) if you don't have whitespace or other troublesome characters in your filenames.
Pushes the whole output of find to your environment, which might be limited. (Using a temporary file rather than that array would solve that, but has other issues - notably concurrent use from multiple shells.)

Related Solutions

Bash – How to apply caret-substitution to the nth-last command

You can't do it with a quick substitution directly, because ^foo^bar is shorthand for:

!!:s/foo/bar/

The !! part (which refers to the last command) isn't part of the quick syntax (that's what makes it quick), but you can use the longer syntax directly and then modify the !! to whatever you want:

!-4:s/foo/bar/

I explained as much of the history syntax as I know in this post; the last section includes the :s modifier

Command Line Interface – General Specification

I recommend reading a book on unix or Linux shell and command line usage, in order to learn basic usage and get a feeling for some advanced features. Then you can turn to reference documentation.

The usage of specific commands is described in their manual. man cat will show the manual of the cat command on your system. Manual pages are usually references, not tutorials, though they often contain examples. On Linux, cat --help shows a terse usage message (meant for quick perusal when you already know the fundamentals and want to find an option for a specific task).

The POSIX standard specifies a minimum set of commands, options and shell features that every unix system is supposed to support. Most current systems by and large support POSIX:2004 (also known as Single UNIX version 3 and the Open Group Base Specifications issue 6). GNU software (the utilities found on Linux) often have many extensions to this minimum set.

There are common conventions for command-line arguments. POSIX specifies utility conventions that most utilities follow, in particular:

Options consist of - followed by a single letter; -ab is shorthand for -a -b.
-- signifies the end of options. For example, in rm -- -a, -a is not an option but an operand, i.e. a file to act upon, so this commands removes the file called -a.
A lone - stands for standard input, where an input file is expected. It stands for standard output where an output file is expected.

GNU utilities and others also support “long options” of the form --name. Some utilities go against the general convention and take multi-letter options with a single leading dash: -name.

Redirection is a shell feature, so you'll find it in your shell's manual. <<< to use a string as standard input is a ksh extension, also supported by bash and zsh. As long as the shell supports it, it can be used on any command.