Post your handy self made command line utilities

Cody Learner · 2017-12-17 13:36:51

Sometimes I prefer man pages in leafpad, with the subject as window title for easy reference when things get busy.

#!/bin/bash
# Opens man page in leafpad with ${1} in the window frame.
# See bash positional parameters for ${1}
# http://mywiki.wooledge.org/BashGuide/Parameters#Special_Parameters_and_Variables
# ${1} = the name of the man page wanted
# [[ -s FILE ]] True if file exists and is not empty.
# Usage: manl bash

MANWIDTH=150 man ${1} > /tmp/${1}
if [[ -s /tmp/${1} ]]; then leafpad /tmp/${1} &
fi
sleep 2; rm /tmp/${1}

Last edited by Cody Learner (2017-12-17 13:56:59)

Trilby · 2017-12-17 14:34:43

If you didn't need title to match, that could just be `man $1 | leafpad /dev/sdtin`

Cody Learner · 2017-12-17 19:19:42

It started out something like 'man bash | leafpad' and evolved over time.

I've never used /dev/sdtin ... interesting

Trilby · 2017-12-17 22:57:08

That took a few tries for me. I installed leafpad to experiment. My first attempt was `man bash | leafpad -` as it is common for programs that take a file as an argument to interpret a "-" where a file name would be to mean read from stdin. Leafpad doesn't seem to use "-" this way, though. Using /dev/stdin is a bit more generic and can be used almost anywhere a filename would be expected (exceptions are when the program requires a "seekable" file). An alternative that would be specific to bash and zsh would be to use process substitution: `leafpad <(man bash)`.

N_BaH · 2017-12-17 23:22:07

remains some questions : why use leafpad? what's its benefit over default pager?

Cody Learner · 2017-12-18 02:16:32

Trilby, you got me playing around with different ways to code it. Getting the title being the difficult part, I ended up back to what I posted. What a convoluted workaround it is.... but it does what is needed.

N_BaHm, most of the time for a quick man page read, I'd never use leafpad. However, when I really get into something, I may have dozens of all types windows open toggling between them as needed. Having 4-5 terminals open just for man pages, along with a several more to work out of, throw in browsers, editors, notes, etc. I also have different colour backgrounds set for working on different things. For reading, I prefer white bg of leafpad, have light and dark gray bg terminal emulators for other stuff, etc. As for man pager, I do find it feels somewhat restrictive to use compared to leafpad. Admittedly though, I've never taken the time to do more than read and search for words with it.

I guess it really boils down to personal preference, old habits, and trying to keep things organized. I've found the window title gives me a quick reference at a glance.

quequotion · 2017-12-22 11:19:24

This revised doomcube-feed doesn't make for a bad, if cryptic, network monitor:

#!/bin/bash
#"advanced" test method
#[[ -n "$1" ]] && interval="$1" || interval="4"
#"simple" test method
interval="$(( $# ? ${1:-0} : 4))"

while true; do

  #clear
  ss -tun | sed -n '2,$s/.* \([0-9\.]*\):\([0-9]*\) *\([0-9\.]*\):\([0-9]*\)/\1 \3 \4/p'
  sleep "${interval}"

done

Example output:

127.0.0.1 55 127.0.0.1 5555
127.0.0.1 555 127.0.0.1 55555
192.168.1.2 55 555.55.555.555 555
192.168.1.2 555 555.555.55.55 5555
192.168.1.2 55 55.555.55.55 5555

I know, there's probably a less elaborate way to achieve that; this was originally meant to replace the input doomcube took from conntrack, so it provides in the same format (though not in real time).

EDIT: simplified as per following advice; outputs both ports--not compatible with doomcube!
Edit again: Choose your own adventure: test method

Last edited by quequotion (2017-12-23 03:39:32)

Trilby · 2017-12-22 13:44:51

That's a ridiculous ammount of sed abuse and pipes to bit by bit split something apart only to then have a while loop putting it back together. Just get what you want the first time:

ss -tun | sed -n 's/^[a-z]*p *[^ ]* *[^ ]* *[^ ]* *\([^:]*\):\([0-9]*\) *\([^:]*\):\([0-9]*\)/\1 \3 \4/p'

You might want a \2 in place of the last \4 depending on which port you're actually looking for - I have no idea what the purpose of this is, but this single sed line would produce the same result as your script.

Or even this should work:

ss -tun | sed -n '2,$s/.* \([0-9\.]*\):\([0-9]*\) *\([0-9\.]*\):\([0-9]*\)/\1 \3 \4/p'

Last edited by Trilby (2017-12-22 13:50:41)

N_BaH · 2017-12-22 13:57:51

hi,

useless use of [[; simple test is enough.
user's variables shouldn't be whole uppercase; it's conventionnally reserved to environment variables.
useless use of grep : ss -tun | sed /^[a-z]*p/{s|[a-z]*p[ ]*[A-Z]*[ ]*[0-9]*[ ]*[0-9]*[ ]*||g;s|-[A-Z]*.*||g;/^$/d}'

pretty complicated, and slow script due to the repeated use of sed and regexes.

why not use mapfile, parse its array, and read each of its lines into a temporary array to get columns data ?

#!/bin/bash

sleeptime=$(( $# ? ${1:-0} : 4))
while true
do
   clear
   mapfile -t -s 1 data < <(ss -tun)
   for l in "${data[@]}"
   do
      read -ra cols <<<"$l"
      echo "${cols[4]%:*} ${cols[5]//:/ }"
   done
   sleep $sleeptime
done

Last edited by N_BaH (2017-12-22 13:59:40)

Trilby · 2017-12-22 14:35:57

If you're going to go that route, you could just replace the colons with spaces in "l' as it's read into cols, then just echo cols 4 6 and 7.

N_BaH · 2017-12-22 16:01:10

right !
this could be done simply by modifying read's IFS :

IFS=' :' read -ra cols <<<"$i"

then echo cols 4 6 7.

quequotion · 2017-12-22 22:33:34

N_BaH wrote:

useless use of [[; simple test is enough.

Is there a computational difference between the two? I am not so familiar with variable manipulation.

Trilby wrote:

You might want a \2 in place of the last \4 depending on which port you're actually looking for - I have no idea what the purpose of this is, but this single sed line would produce the same result as your script.

doomcube displays connections as coordinates inside a cube, with srcip, destip, and destport (\4) as x, y, and z. For monitoring purposes you'd probably want to see both, but to map that would require a 4-dimensional doomcube.

As usual good advice.

doomcube now shipping with simplified doomcube-feed.

Last edited by quequotion (2017-12-23 00:48:18)

N_BaH · 2017-12-22 23:05:15

Is there a computational difference between the two?

I don't know. probably not : they're both internal commands.
imo, simple test do not need advanced test.
and it's worth telling what we're doing : simple OR advanced test.

Last edited by N_BaH (2017-12-22 23:07:32)

jasonwryan · 2017-12-22 23:10:01

If you are using bash as your shebang, use [[: it is a better approach.

Trilby · 2017-12-22 23:48:42

jasonwryan wrote:

If you are using bash as your shebang, use [[: it is a better approach.

I disagree. It is more featureful. But if you aren't using any of those added features, it doesn't help any, and hurts portability. There is no reason to habitually use [[ except for that habit protecting one from having to know the difference between the two and know when [[ would actually be better.

The difference between the two in this case is that [ is more portable (and if anyone thinks portability is a moot point when using a bash shebang, please first read my link). I would, however, never refer to a [[ as "useless use", though I do wish [[ was not explicitly encouraged where not needed.

EDIT:

Oh dear god! I just saw the edit to the first doomcube post. Ok, all this [ vs [[ is very trivial quibling, but that monstrosity must die. You have a subshell feeding line by line into a while loop doing nothing put printing each line it reads! STOP. The following are equivalent, except the first one is horrifically ugly:

while read -r line; do
    echo "${line}"
  done <<< "$(some command)"

some command

This difference is not subtle. The [ vs [[ question is like debating whether the toilet paper should roll over the top or under the bottom, but that while loop is like coming home to find your kids eating the toilet paper.

Last edited by Trilby (2017-12-22 23:57:51)

jasonwryan · 2017-12-23 00:29:45

Trilby, I'm happy to continue to disagree. If you (that's anyone, not you specifically) want to write portable code, then use sh as your shebang. If you are writing for the bash shell, then a) you should be aware of that fact, and b) leverage it by using the advantages that choice affords, `[[` being one.

quequotion · 2017-12-23 00:43:40

Trilby wrote:

Oh dear god!

lol, fixed. The original script I wrote quite a while ago. I think I wrote it this way at the time because my initial approach caused things like empty lines (just \n) and other nonsense that crashed or caused errors for doomcube when it was fed more than one line at a time.

Trilby · 2017-12-23 00:54:42

jasonwryan wrote:

leverage it by using the advantages that choice affords, `[[` being one.

That's my point, [[ is not an advantage for simple conditionals. It is no better than [ for simple tests. It can do things that [ can't, but if you aren't doing one of those things, it's not needed.

N_BaH · 2017-12-23 01:06:13

« not needed » aka "useless" ?

Trilby · 2017-12-23 01:46:53

Well yes, but it, or an alternative was needed. You (and I) just favor an alternative. I favor [ for portability sake, other than that there is no reason at all to favor it. So [[ is not useless. Someone of an alternative view favoring [[ could just as well say you had a useless use of [ where you should have used [[, as [ was not strictly needed because [[ can take it's place. There is nothing in the cade that required [[ over [, but just the same there was also nothing in the code that required [ over [[.

"Useless use of ..." is generally associated with objectively incorrect uses of tools that are not needed at all. If an awk implementation is called for, someone opting for gawk, or nawk, instead of just awk would not be useless. Trying to cat a file to a pipe to any one of these three, in contrast, is a useless use of cat.

Note that portability is the only cost of using [[. If [ was more efficient or less resource intensive, then you could argue [[ was useless when it's advanced features weren't called for: why use a slow bloated tool when a lighter one will do the job just fine. However that's not at all the case. [[ can in some cases be faster (undetectably so unless you're looping in the KHz range).

Last edited by Trilby (2017-12-23 01:52:24)

quequotion · 2017-12-23 03:26:38

Trilby wrote:

There is no reason to habitually use [[ except for that habit protecting one from having to know the difference between the two and know when [[ would actually be better.

For my two cents, if there's no significant overhead or otherwise waste of more than the extra keystrokes, I see having less syntax to think about as generally a good thing--and a perfectly valid reason to use less syntax, even if it is lazy. I'll worry about portability when someone asks for it

Last edited by quequotion (2017-12-23 09:36:47)

eschwartz · 2017-12-24 00:07:59

Meh. If you're trying to port a script from bash to POSIX sh and you're not using shellcheck/checkbashisms, you're probably doing it wrong. The bash [[ keyword vs. the POSIX [ builtin is the kind of thing you can detect and fix with 100% accuracy, and even fix with an automated script kind of like Python's 2to3.

If your script is relevant enough that people want to port it to POSIX, and simple enough that fixing [[ bashisms is one of the more significant changes that that script needs to undergo in order to be POSIX compatible, then a prospective porter will have no meaningful trouble anyway -- although likewise, the original author wouldn't, and should therefore have considered writing in POSIX from the get-go.

I feel like we're basically arguing whether scripts that don't really use bash-specific functionality, should inherit bash syntax "just because" when specifying #!/bin/bash as the shebang. It's completely missing the point, which is that the question is only relevant in cases where there's a better question anyway -- and therefore the question is again no longer relevant.

Just write your script in POSIX, and use #!/bin/sh. If you're worried about the insignificant speed increase of using [[, you can get a very significant speed increase by using /bin/sh symlinked to the dash shell (or busybox ash, if that floats your boat), available from the official repos!

I hope everyone is happy now.

whatshisname · 2017-12-27 18:00:50

I run XFCE on my laptop and it doesn't have a handy utility for connecting to wireless AP's when on the road so I've been manually connecting when travelling. It's always a pain. So I decided to script it.

This creates an item in /etc/netctl with the name of the SSID of the AP to be started and stopped with netctl. Run it with "sudo" so you can write to /etc/netctl as well as bring the network interface up and down.

You need to define the name of your wireless interface. The script prompts you for everything else and reminds you how to connect with netctl at the end.

Looking forward to improvements/suggestions:

#!/bin/sh

# Run this script with sudo.

# Define the wireless interface for this script
NIC=wlp2s0

echo "Bringing up network and scanning for SSID's ..."

UP=$(ip addr show $NIC | grep UP)

# The quotes around "$UP" were critical
if [ -n "$UP" ]
then
   echo "NIC is up"
else
   echo "Bringing up $NIC"
   ip link set $NIC up
fi

echo "Scanning for SSID's ..."

iw $NIC scan | grep SSID

echo 'SSID to connect to? '
read -r ESSID

echo "Password for $ESSID: "
read -r PASSWORD

OUT=/etc/netctl/$ESSID
# ----------

cat <<  EOF > "$OUT"

Description='A simple WPA encrypted wireless connection'
Interface=wlp2s0
Connection=wireless

Security=wpa
IP=dhcp

ESSID='$ESSID'
Key='$PASSWORD'
EOF

# Taking NIC down in preparation for netctl startup 'cause netctl assumes the NIC is down.
ip link set $NIC down

echo "Starting connection for $ESSID"
netctl start $ESSID

echo "If you're at a motel or public place that requires accepting a network agreement, bring up your favorite browser and proceed."
echo ""
echo "For convenience at this location, 'sudo netctl enable $ESSID'.  Disable later with 'sudo netctl disable $ESSID'".

(Edited for grammar and to add "sudo" to the final instructions.)

Last edited by whatshisname (2017-12-27 21:08:34)

eschwartz · 2017-12-27 22:17:55

What is the advantage of this over netctl's wifi-menu for interactively selecting the ESSID to connect to, and saving netctl profiles for use with the netctl-auto service?

Or the NetworkManager daemon with either nmtui (console) or network-manager-applet (gui) as a frontend?

Trilby · 2017-12-27 22:22:32

Eschwartz, I'd ask similar questions about netctl in general over wpa_supplicant and wpa_passprhase.

Arch Linux

#3101 2017-12-17 13:36:51

Re: Post your handy self made command line utilities

#3102 2017-12-17 14:34:43

Re: Post your handy self made command line utilities

#3103 2017-12-17 19:19:42

Re: Post your handy self made command line utilities

#3104 2017-12-17 22:57:08

Re: Post your handy self made command line utilities

#3105 2017-12-17 23:22:07

Re: Post your handy self made command line utilities

#3106 2017-12-18 02:16:32

Re: Post your handy self made command line utilities

#3107 2017-12-22 11:19:24

Re: Post your handy self made command line utilities

#3108 2017-12-22 13:44:51

Re: Post your handy self made command line utilities

#3109 2017-12-22 13:57:51

Re: Post your handy self made command line utilities

#3110 2017-12-22 14:35:57

Re: Post your handy self made command line utilities

#3111 2017-12-22 16:01:10

Re: Post your handy self made command line utilities

#3112 2017-12-22 22:33:34

Re: Post your handy self made command line utilities

#3113 2017-12-22 23:05:15

Re: Post your handy self made command line utilities

#3114 2017-12-22 23:10:01

Re: Post your handy self made command line utilities

#3115 2017-12-22 23:48:42

Re: Post your handy self made command line utilities

#3116 2017-12-23 00:29:45

Re: Post your handy self made command line utilities

#3117 2017-12-23 00:43:40

Re: Post your handy self made command line utilities

#3118 2017-12-23 00:54:42

Re: Post your handy self made command line utilities

#3119 2017-12-23 01:06:13

Re: Post your handy self made command line utilities

#3120 2017-12-23 01:46:53

Re: Post your handy self made command line utilities

#3121 2017-12-23 03:26:38

Re: Post your handy self made command line utilities

#3122 2017-12-24 00:07:59

Re: Post your handy self made command line utilities

#3123 2017-12-27 18:00:50

Re: Post your handy self made command line utilities

#3124 2017-12-27 22:17:55

Re: Post your handy self made command line utilities

#3125 2017-12-27 22:22:32

Re: Post your handy self made command line utilities

Board footer