switch to terminal input after executable gnuplot script - unix

This is a gnuplot scripting question on unix like systems.
For shell executable gnuplot scripts starting like:-
#!/opt/local/bin/gnuplot
how do you switch to the gnuplot prompt in the starting terminal session, at the end of the script?
Adding
load "/dev/stdin"
at the end, switches the input, but gives no user prompt.
I would like to let the user replot their own data over the setup and background generated by the script, and/or enter other gnuplot commands. I am looking for an elegant solution within gnuplot. When using the #!/opt/local/bin/gnuplot -c in a gnuplot scriptfile (after a chmod +x), I would like ./script.gp to work the same way as call "script.gp" from gnuplot does. This is so we could subsequently replot "info.dat" at a gnuplot prompt in each case. I want to switch gnuplot from batch mode to interactive at the end of the script (probably like in the way a startup file would). I can't remember or find the command/trick for this (load "/dev/stdin" is close).
The plot window in this case is AquaTerm, gnuplot 5.0 patchlevel 3 (macports), and the terminal session is OS X "Terminal". --persist seems unhelpful in changing the experience.

You want to send a load of plot commands from a file to gnuplot, then send a load of commands from your user's terminal, which suggests something like this:
{ cat plot.gp; while read cmd; do echo "$cmd"; done; } | gnuplot
Or if I flesh that out a bit:
{ cat plot.gp; while :; do >&2 echo -n "gnuplot> "; read -re c; [ "$c" == "quit" ] && break; echo "$c"; done; } | gnuplot
I am using this plot.gp
set xrange [-5:5]
plot sin(x),cos(x),x*x
That basic functionality can be spruced up quite a lot, if you feel fancy:
#!/bin/bash
gpfile=$1
{
# Show user gnuplot version - on stderr because stdout is going to gnuplot
gnuplot -e "show version" >&2
# Strip shebang (but not comments) from plot commands and send to gnuplot
grep -v "^#!" "$gpfile"
# Show plot commands from file to user - on stderr and prefixed with pseudo-prompt
grep -v "^#!" "$gpfile" | sed 's/^/gnuplot> /' >&2
# Read user input and forward onto gnuplot
while :; do
>&2 echo -n "gnuplot> "
read -re c
[ "$c" == "quit" ] && break
echo "$c"
done
} | gnuplot
You would save the above in a file called plotandinteract in your HOME directory, then make it executable (just once) with:
chmod +x $HOME/plotandinteract
Then you can run it with:
$HOME/plotandinteract SomePlotFile
There's probably a much more elegant solution with Tcl/expect but I can't work that out - looks like I need #GlennJackman again :-)

Related

zsh completion to use word at cursor to run command

I have been trying to grok how to write zsh completions, but he gap between understanding Create Basic ZSH-Command with Auto-Completion (super simple example and easy to understand) and zsh completions howto got to me and I couldn't figure this out. I am sure there are builtins to do this.
My goal: write a completion function that takes what I have typed, runs a command with it and spits out the result as the completion options. Most likely: take what I typed, grep through the files in some dir for that token and output the result.
This is as far as I have taken it:
runCommandOnFile() {
echo "Run on file: $1"
}
_runCommandOnFile() {
# Does not show grep results like I expect.
# compadd $(ls ~/dir/to/search | grep ${PREFIX})
# Spits out list of all files in dir.
compadd $(ls ~/dir/to/search)
}
compdef _runCommandOnFile runCommandOnFile
I read that ${PREFIX} holds what was typed, but grepping with this isn't working as I expected.
I see that there are already existing functions to do regex etc, but I cannot see how that relates to an example like mine.
In bash for jump and mark, I achieved this result like so:
_marks_complete() {
local curw=${COMP_WORDS[COMP_CWORD]}
local word=${COMP_WORDS[COMP_CWORD]}
COMPREPLY=()
for file in $(find "${MARKPATH}" -type l -iname "*${word}*" -printf "%f\n") ; do
# If the glob doesn't match, we'll get the glob itself, so make sure
# we have an existing file
COMPREPLY+=( "${file}" )
done
return 0
}
complete -F _marks_complete jump unmark

How to close all windows to the right in tmux

Is there a way to issue a command to close all tmux windows unless something is open in that window? For example, an open file, a running process, etc.?
I am hoping for something that functions as a web browser where you can right click and select close all other tabs to the right. I'd like to issue this in tmux, and similar to the web browser example, have "busy" windows or panes prompt me to close them or silently fail to close.
I have seen this question, but I don't necessarily want to issue the command to all windows.
Here's a shell alternative:
for win_id in $(tmux list-windows -F '#{window_active} #{window_id}' | awk '/^1/ { active=1; next } active { print $2 }'); do tmux kill-window -t "$win_id"; done
And here's the same (readable version):
for win_id in $(tmux list-windows -F '#{window_active} #{window_id}' | \
awk '/^1/ { active=1; next } active { print $2 }')
do
tmux kill-window -t "$win_id"
done
Edit: I made a plugin with this!
https://github.com/pschmitt/tmux-forsaken
I just built a script to do so, here it is:
#!/usr/bin/env python3
import subprocess
import os
import re
result = subprocess.run(['tmux', 'list-windows'], stdout=subprocess.PIPE)
result = result.stdout.decode('utf-8')
lines = result.splitlines()
should_close_next = False
for line in lines:
if should_close_next:
window = line.split(':')[0]
os.system(f'tmux kill-window -t {window}')
continue
match = re.search("active", line)
if match:
should_close_next = True
And to integrate it with your tmux add to your tmux.conf
bind-key "k" run-shell "kill_panes_to_right.py\n"
Best

How can I tell if a makefile is being run from an interactive shell?

I have a makefile which runs commands that can take a while. I'd like those commands to be chatty if the build is initiated from an interactive shell but quieter if not (specifically, by cron). Something along the lines of (pseudocode):
foo_opts = -a -b -c
if (make was invoked from an interactive shell):
foo_opts += --verbose
all: bar baz
foo $(foo_opts)
This is GNU make. If the specifics of what I'm doing matter, I can edit the question.
It isn't strictly determining whether it is invoked from an interactive shell or not, but for a cron job in which the output is redirected to a file, the answer to this question would be the same as for How to detect if my shell script is running through a pipe?:
if [ -t 0 ]
then
# input is from a terminal
fi
Edit: To use this to set a variable in a Makefile (in GNU make, that is):
INTERACTIVE:=$(shell [ -t 0 ] && echo 1)
ifdef INTERACTIVE
# is a terminal
else
# cron job
endif
http://www.faqs.org/faqs/unix-faq/faq/part5/section-5.html
5.5) How can I tell if I am running an interactive shell?
In the C shell category, look for the variable $prompt.
In the Bourne shell category, you can look for the variable $PS1,
however, it is better to check the variable $-. If $- contains
an 'i', the shell is interactive. Test like so:
case $- in
*i*) # do things for interactive shell
;;
*) # do things for non-interactive shell
;;
esac
I do not think you can easily find out. I suggest adopting an alternative strategy, probably by quelling the verbose output from the cron job. I would look to do that using a makefile like this:
VERBOSE = --verbose
foo_opts = -a -b -c ${VERBOSE}
all: bar baz
foo $(foo_opts)
Then, in the cron job, specify:
make VERBOSE=
This command-line specification of VERBOSE overrides the one in the makefile (and cannot be changed by the makefile). That way, the specialized task (cron job) that you set up once and use many times will be done without the verbose output; the general task of building will be done verbosely (unless you elect to override the verbose-ness on the command line).
One minor advantage of this technique is that it will work with any variant of make; it does not depend on any GNU Make facility.
I’m not really sure what "am interactive" means. Do you mean if you have a valid /dev/tty? If so, then you could check that. Most of us check isatty on stdin, though, because it answers the questions we want to know: is there someone there to type something.
Just a note: you can also see the related discussion that I had about detecting redirection of STDOUT from inside a Makefile.
I believe it will be helpful to readers of this question - executive summary:
-include piped.mk
all: piped.mk
ifeq ($(PIPED),1)
#echo Output of make is piped because PIPED is ${PIPED}
else
#echo Output of make is NOT piped because PIPED is ${PIPED}
endif
#rm -f piped.mk
piped.mk:
#[ -t 1 ] && PIPED=0 || PIPED=1 ; echo "PIPED=$${PIPED}" > piped.mk
$ make
Output of make is NOT piped because PIPED is 0
$ make | more
Output of make is piped because PIPED is 1
In my answer there I explain why the [-t 1] has to be done in an action and not in a variable assignment (as in the recommended answer here), as well as the various pitfalls regarding re-evaluation of a generated Makefile (i.e. the piped.mk above).
The term interactive in this question seems to imply redirection of STDIN... in which case replacing [ -t 1 ] with [ -t 0 ] in my code above should work as-is.
Hope this helps.

ksh: how to probe stdin?

I want my ksh script to have different behaviors depending on whether there is something incoming through stdin or not:
(1) cat file.txt | ./script.ksh (then do "cat <&0 >./tmp.dat" and process tmp.dat)
vs. (2) ./script.ksh (then process $1 which must be a readable regular file)
Checking for stdin to see if it is a terminal[ -t 0 ] is not helpful, because my script is called from an other script.
Doing "cat <&0 >./tmp.dat" to check tmp.dat's size hangs up waiting for an EOF from stdin if stdin is "empty" (2nd case).
How to just check if stdin is "empty" or not?!
EDIT: You are running on HP-UX
Tested [ -t 0 ] on HP-UX and it appears to be working for me. I have used the following setup:
/tmp/x.ksh:
#!/bin/ksh
/tmp/y.ksh
/tmp/y.ksh:
#!/bin/ksh
test -t 0 && echo "terminal!"
Running /tmp/x.ksh prints: terminal!
Could you confirm the above on your platform, and/or provide an alternate test setup more closely reflecting your situation? Is your script ultimately spawned by cron?
EDIT 2
If desperate, and if Perl is available, define:
stdin_ready() {
TIMEOUT=$1; shift
perl -e '
my $rin = "";
vec($rin,fileno(STDIN),1) = 1;
select($rout=$rin, undef, undef, '$TIMEOUT') < 1 && exit 1;
'
}
stdin_ready 1 || 'stdin not ready in 1 second, assuming terminal'
EDIT 3
Please note that the timeout may need to be significant if your input comes from sort, ssh etc. (all these programs can spawn and establish the pipe with your script seconds or minutes before producing any data over it.) Also, using a hefty timeout may dramatically penalize your script when there is nothing on the input to begin with (e.g. terminal.)
If potentially large timeouts are a problem, and if you can influence the way in which your script is called, then you may want to force the callers to explicitly instruct your program whether stdin should be used, via a custom option or in the standard GNU or tar manner (e.g. script [options [--]] FILE ..., where FILE can be a file name, a - to denote standard input, or a combination thereof, and your script would only read from standard input if - were passed in as a parameter.)
This strategy works for bash, and would likely work for ksh. Poll 'tty':
#!/bin/bash
set -a
if [ "$( tty )" == 'not a tty' ]
then
STDIN_DATA_PRESENT=1
else
STDIN_DATA_PRESENT=0
fi
if [ ${STDIN_DATA_PRESENT} -eq 1 ]
then
echo "Input was found."
else
echo "Input was not found."
fi
Why not solve this in a more traditional way, and use the command line argument to indicate that the data will be coming from stdin?
For an example, consider the difference between:
echo foo | cat -
and
echo foo > /tmp/test.txt
cat /tmp/test.txt

Breaking out of "tail -f" that's being read by a "while read" loop in HP-UX

I'm trying to write a (sh -bourne shell) script that processes lines as they are written to a file. I'm attempting to do this by feeding the output of tail -f into a while read loop. This tactic seems to be proper based on my research in Google as well as this question dealing with a similar issue, but using bash.
From what I've read, it seems that I should be able to break out of the loop when the file being followed ceases to exist. It doesn't. In fact, it seems the only way I can break out of this is to kill the process in another session. tail does seem to be working fine otherwise as testing with this:
touch file
tail -f file | while read line
do
echo $line
done
Data I append to file in another session appears just file from the loop processing written above.
This is on HP-UX version B.11.23.
Thanks for any help/insight you can provide!
If you want to break out, when your file does not exist any more, just do it:
test -f file || break
Placing this in your loop, should break out.
The remaining problem is, how to break the read line, as this is blocking.
This could you do by applying a timeout, like read -t 5 line. Then every 5 second the read returns, and in case the file does not longer exist, the loop will break. Attention: Create your loop that it can handle the case, that the read times out, but the file is still present.
EDIT: Seems that with timeout read returns false, so you could combine the test with the timeout, the result would be:
tail -f test.file | while read -t 3 line || test -f test.file; do
some stuff with $line
done
I don't know about HP-UX tail but GNU tail has the --follow=name option which will follow the file by name (by re-opening the file every few seconds instead of reading from the same file descriptor which will not detect if the file is unlinked) and will exit when the filename used to open the file is unlinked:
tail --follow=name test.txt
Unless you're using GNU tail, there is no way it'll terminate of its own accord when following a file. The -f option is really only meant for interactive monitoring--indeed, I have a book that says that -f "is unlikely to be of use in shell scripts".
But for a solution to the problem, I'm not wholly sure this isn't an over-engineered way to do it, but I figured you could send the tail to a FIFO, then have a function or script that checked the file for existence and killed off the tail if it'd been unlinked.
#!/bin/sh
sentinel ()
{
while true
do
if [ ! -e $1 ]
then
kill $2
rm /tmp/$1
break
fi
done
}
touch $1
mkfifo /tmp/$1
tail -f $1 >/tmp/$1 &
sentinel $1 $! &
cat /tmp/$1 | while read line
do
echo $line
done
Did some naïve testing, and it seems to work okay, and not leave any garbage lying around.
I've never been happy with this answer but I have not found an alternative either:
kill $(ps -o pid,cmd --no-headers --ppid $$ | grep tail | awk '{print $1}')
Get all processes that are children of the current process, look for the tail, print out the first column (tail's pid), and kill it. Sin-freaking-ugly indeed, such is life.
The following approach backgrounds the tail -f file command, echos its process id plus a custom string prefix (here tailpid: ) to the while loop where the line with the custom string prefix triggers another (backgrounded) while loop that every 5 seconds checks if file is still existing. If not, tail -f file gets killed and the subshell containing the backgrounded while loop exits.
# cf. "The Heirloom Bourne Shell",
# http://heirloom.sourceforge.net/sh.html,
# http://sourceforge.net/projects/heirloom/files/heirloom-sh/ and
# http://freecode.com/projects/bournesh
/usr/local/bin/bournesh -c '
touch file
(tail -f file & echo "tailpid: ${!}" ) | while IFS="" read -r line
do
case "$line" in
tailpid:*) while sleep 5; do
#echo hello;
if [ ! -f file ]; then
IFS=" "; set -- ${line}
kill -HUP "$2"
exit
fi
done &
continue ;;
esac
echo "$line"
done
echo exiting ...
'

Resources