In what way? What was posted is the default content of dmenu_run. What were you doing before?
Yes, right. Thanks for correcting me. What I were doing before was testing with bemenu (because I am in sway) all the time. I thought they will be same in the sense of what I was trying.
Therefore, I checked everything with both of dmenu and bemenu. According to my tests (I'm not sure, but this is what I found so far), tty -s || exit 0 works with dmenu as I expected. I think, I did messing up this thread by my carelessness. Sorry!
Thanks, launching dmenu by that way makes tty -s || exit 1 works.
In what way? What was posted is the default content of dmenu_run. What were you doing before?
Anything that allows for the `tty -s || exit` line to work would also allow the `[ -t 0 ]` test to work as they do exactly the same thing, except the latter doesn't require calling an external binary.
]]>dmenu_run just passes entered string to shell:
#!/bin/sh dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &
From script's point of view there is no difference between running "in terminal" or "from dmenu": it is running in the same envoronment from which dmenu_run is invoked.
Thanks, launching dmenu by that way makes tty -s || exit 1 works.
From script's point of view there is no difference between running "in terminal" or "from dmenu": it is running in the same envoronment from which dmenu_run is invoked.
noted with thanks.
]]>#!/bin/sh
dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &
From script's point of view there is no difference between running "in terminal" or "from dmenu": it is running in the same envoronment from which dmenu_run is invoked.
]]>That command "works" in the sense that it does exactly what it's supposed to - the problem is that even what it's supposed to do isn't really relevant to your problem.
That's why I am looking for a way other than that command.
]]>Respectfully, to produce a scenario, could anyone please put the following small script in anywhere of $PATH and execute via dmenu/bemenu (not in terminal).
#!/bin/bash
tty -s || exit 0
notify-send "the script was executed via dmenu" "the script did not stop at the line above \"tty -s || exit 0\""
.
The result I want is that if I execute the script from dmenu, I want the script to stop at the line tty -s || exit 0
But it doesn't. It always continue to the line of notify-send ....
Is it only me that tty -s || exit 0 doesn't work?
tty -s || exit 1
[ -z "$FOO" ] && echo bar
[ -z "$PATH" ] && echo bar
But unless you can rely on shell specifics, the problem is s a bit more nuanced w/ this approach, https://stackoverflow.com/questions/360 … et-in-bash
If you revert the approach and test for a variable that's explicitly set to a defined value, it becomes easier.
CONTEXT_DMENU="dmenu"
[ "$CONTEXT_DMENU" = "dmenu" ] && echo bar
unset CONTEXT_DMENU
[ "$CONTEXT_DMENU" = "dmenu" ] && echo bar
However:
But testing for available stdin/stdout and explicitly closing that from the dmenu script is the by far more generic and robust approach.
But if they are to modify the dmenu_run (or equivalent) script anyways, they may as well fix it properly by closing stdin (and / or redirecting it from /dev/null)
#!/bin/bash
read -e -t 3 -i "Yes" -p "say Yes in 3 sec: " yescontinue
[ -z "$yescontinue" ] && notify-send -t 3000 "the script has been closed" "for no user input" && exit 0
echo "continue..."
echo "$yescontinue" > /dev/null
if [[ "$1" == "--prvdir" && ! -z "$2" ]]; then
echo "private directory name was given..."
else
notify-send -t 3000 "the script has been closed" "private directory was not given"
exit 0
fi
if lsmod | grep -wq "^ecryptfs"; then
echo "module was loaded..."
else
echo "load ecryptfs kernel module first"
echo "run # modprobe ecryptfs"
exit 0
fi
if which ecryptfs-wrap-passphrase > /dev/null 2>&1; then
echo "commands are available..."
else
echo "commands are not available"
echo "install <ecryptfs-utils> package"
exit 0
fi
mkdir -p $HOME/.myprivatedata
prvd=$HOME/.myprivatedata/"$2"
prvs=$HOME/.myprivatedata/."$2"
if df -T | grep -wq "$prvd"; then
echo "already mounted, check first"
exit 0
fi
if [ -d "$prvd" ]; then
echo ""$prvd" exits, check first"
exit 0
fi
if [ -d "$prvs" ]; then
echo ""$prvs" exits, check first"
exit 0
fi
mkdir -p "$prvd" "$prvs"
mkdir -p ~/.ecryptfs
wppf=~/.ecryptfs/"$2".wp
conf=~/.ecryptfs/"$2".conf
sigf=~/.ecryptfs/"$2".sig
if [[ -f "$wppf" && -f "$conf" && -f "$sigf" ]]; then
echo "all config files exit, trying mount first..."
echo "if it didn't work, delete all config files or change private directory name, and rerun this script"
mount.ecryptfs_private "$2"
exit 0
else
echo "continue for creating config files..."
fi
ecryptfs-wrap-passphrase ~/.ecryptfs/"$2".wp
echo "Passphrase has been wrapped into ~/.ecryptfs/"$2".wp file."
echo "$prvs" "$prvd" ecryptfs > ~/.ecryptfs/"$2".conf
( stty -echo; printf "Passphrase: " 1>&2; read PASSWORD; stty echo; echo $PASSWORD; ) | \
ecryptfs-insert-wrapped-passphrase-into-keyring ~/.ecryptfs/"$2".wp - > /tmp/ecryptfs-insert-key
sigkey=$(cat /tmp/ecryptfs-insert-key | awk -F '[][]' '/Inserted auth tok with sig/ {print $2}')
echo "$sigkey" > ~/.ecryptfs/"$2".sig
echo "$sigkey" >> ~/.ecryptfs/"$2".sig
echo "config files have been created successfully and trying to mount..."
mount.ecryptfs_private "$2"
rm /tmp/ecryptfs-insert-key
df -T | grep "$prvd"
Thank you all.
]]>... it might be better to explicitly export a variable from the dmenu script and unset it w/ your interactive shell RC.
I agree that this would be better than my secondary suggestion. But if they are to modify the dmenu_run (or equivalent) script anyways, they may as well fix it properly by closing stdin (and / or redirecting it from /dev/null) which would be far better than either of the environment variable options.
]]>Alternatively you could go for Trilby's 2nd suggestion and test for an environment variable that indicates the context.
Since your dmenu script might pick up the environment from an interactive shell it might be better to explicitly export a variable from the dmenu script and unset it w/ your interactive shell RC.
But testing for available stdin/stdout and explicitly closing that from the dmenu script is the by far more generic and robust approach.
Testing $1 only makes sense if you always call the script w/ a parameter but do never call it accidentally w/ a parameter from dmenu.
$1 isn't related to the IO