Handy command-line stuff for terminals or scripts

johnraff · 2016-01-09 03:28:12

^I understand the use of eval is perfectly safe here because it's arguments are quite restricted, but having been trained to avoid it as something evil, I remembered declare -p as another way of getting a variable's state:

is_set() { declare -p $1 >/dev/null 2>&1;}
is_empty(){ is_set $1 && ! [[ ${!1} ]];}

This seems to do the same while being slightly easier to read - for me anyway...

However, it depends on 'declare -p' returning failure if given an unset variable. I presume that can be relied upon?

Last edited by johnraff (2016-02-16 06:26:41)

xaos52 · 2016-01-09 12:16:48

^ Agreed.

This comes up every so often. Searching for recent solutions, I found out that since bash 4.2 there is a command to test if a variable is set.

is_set() { [[ -v $1 ]];}
is_empty(){ is_set $1 && ! [[ ${!1} ]];}

works.

KrunchTime · 2016-01-10 00:34:44

This tip comes from Matthew Garrett via the Jan 2016 issue of Linux Voice (page 16):

Forgot to type sudo before a command? sudo!! will re-run the previous command under sudo. But not just sudo; it can be used to precede the previous command with whatever comes before the !!.

Head_on_a_Stick · 2016-01-10 00:43:41

In a similar vein:

Warning: this link contains profanity

That program is in the official Arch repositories and is actually tremendously useful.

I suppose you could always alias it to something else if the swearing bothered you.

Horizon_Brave · 2016-01-10 02:10:48

KrunchTime wrote:

This tip comes from Matthew Garrett via the Jan 2016 issue of Linux Voice (page 16):
Forgot to type sudo before a command? sudo!! will re-run the previous command under sudo. But not just sudo; it can be used to precede the previous command with whatever comes before the !!.

Oh man, that is good... but knowing me, I'd forget to add more than one exclamation mark or something, making it easier just to retype the command with sudo in front tongue But yea this is a good one!

Horizon_Brave · 2016-01-13 19:44:25

Hey guys, has anyone used the tool 'ethtool' command?
ethtool man page

As someone who does a lot of work on servers running linux that need to be plugged into switches and using a lot of virtual VM's at work this cool command is a great way to query the layer 2 interface stats. Check out some of the layer of detail you can get:

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: yes

And you can issue commands and changes to the interfaces!

# ethtool -s eth0 speed 100 autoneg off

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  Not reported
        Advertised auto-negotiation: No
        Speed: Unknown! (65535)
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: off

Maybe it's just me, but I think this is pretty awesome!

Horizon_Brave · 2016-01-25 04:46:43

Well this is something that's probably well known to many of you, but a nifty safety guard for those still trying to get into the habit of remembering to "append" rather than "overwrite"

kingghidorah@bunsen:~$ set +o noclobber

kingghidorah@bunsen:~$ echo some_text_here > test.txt


kingghidorah@bunsen:~$ echo some_new_text > test.txt

bash: test.txt: cannot overwrite existing file

kingghidorah@bunsen:~$ echo some_good_text >> test.txt


kingghidorah@bunsen:~$


kingghidorah@bunsen:~$ cat test.txt
some_text_here
some_good_text

So basically keep the noclobber variable set and it'll force you to get into the habit of adding the double >> to append!

becker_11 · 2016-08-01 08:00:27

This returns the size (in human readable format) of the current directories contents excluding any subdirectories.

ls -lh | head -1

becker_11 · 2016-08-01 08:03:14

Horizon_Brave wrote:

KrunchTime wrote:
This tip comes from Matthew Garrett via the Jan 2016 issue of Linux Voice (page 16):
Forgot to type sudo before a command? sudo!! will re-run the previous command under sudo. But not just sudo; it can be used to precede the previous command with whatever comes before the !!.

Oh man, that is good... but knowing me, I'd forget to add more than one exclamation mark or something, making it easier just to retype the command with sudo in front But yea this is a good one!

To add sudo to the previous command press "up arrow" then "Ctrl+a" to move the cursor to the beginning of the line. Then add "sudo" & press enter.

Nili · 2016-08-01 15:45:52

I like the "calendar" command

nili ~ $ calendar
Aug 01 	Herman Melville born, 1819
Aug 01 	Lughnasa; Feast of the god Lugh, a 30 day Celtic feast centers on this day
Aug 01 	Discovery Day in Trinidad and Tobago
Aug 01 	Emancipation Day in Granada
Aug 01 	Founding of Asuncion in Paraguay
Aug 01 	Freedom Day in Guyana
Aug 01 	National Day in Switzerland
Aug 01 	National Holidays (5 days) in El Salvador
Aug 01 	Parent's Day in Zaire
Aug 01 	The Concert for Bangla Desh takes place at Madison Square Garden, 1971
Aug 01 	Lugnasad / Lughnasada / Lunasa - Gaelic summer "games of Lug" (sun-god)
Aug 01*	Summer bank holiday (Scotland)
Aug 02 	Our Lady of Los Angeles in Costa Rica
Aug 02*	Parshat Tetzaveh
Aug 02 	Lady Godiva Day
Aug 02 	Gabor Kovesdan <gabor@FreeBSD.org> born in Budapest, Hungary, 1987

johnraff · 2017-05-12 07:01:49

You'll often read that it's not a good idea to use upper-case variable names in scripts, because they might clash with one of the environment variables, which are all upper-case. I was reminded of this yesterday, after spending almost a day trying to debug a script which was trying to use an ssh connection. It failed to put up a passphrase entry box, so errored out for lack of authentication, even though the same command was working OK when run by itself.

It turned out I was using 'TERM=x-terminal-emulator' at one point. Of course everyone knows (right?) that TERM is an important environment variable (try 'echo $TERM') and by overwriting it I was breaking ssh's pseudo-tty function so I couldn't enter the passphrase.

So... DON'T USE UPPER-CASE VARIABLE NAMES.

Head_on_a_Stick · 2017-05-12 07:03:11

^ also: never force $TERM, it breaks things.

Always let the terminal emulator set that variable.

Last edited by Head_on_a_Stick (2017-05-12 07:03:36)

Horizon_Brave · 2017-05-12 18:45:19

Need a script checker to check for variable collisions for not just internal variables but checks the env. variables too!

johnraff · 2017-05-13 03:24:17

^Just avoid upper case and you'll be OK. All envvars are UC.

ohnonot · 2017-05-13 12:07:17

^ and for readability, i found that the under_score really helps to make variables stand out visually. more so than camelCase, which i hate, hate, hate with a passion.
and never make the string 'var' part of your variable! that's like naming your domain something-online.com.

misko_2083 · 2017-05-13 14:51:57

Horizon_Brave wrote:

Need a script checker to check for variable collisions for not just internal variables but checks the env. variables too!

It checks if the variable is in the env,
or in the script (if the variables are not already set in the env).

#!/usr/bin/env bash

printf "%s" "Enter the variable: " 
read VAR

# Check if the variable exists in the environment
for var in $(set | egrep "^\w+=")
 do [[ "${var%%'='*}" == "$VAR" ]] && echo "Var $VAR exists in env"
done

# Store the variables before source
VARS="$(set | egrep "^\w+=")"

# Source some script
# source /home/misko/Desktop/pmrp2
# or declare some variable here
TEST=

# Get the variables after source
# and exclude the stored ones
# grep -vFe "$VARS" <<<"$(set | egrep "^\w+=")" | grep -v ^VARS=
# Compare [[ "${var%%'='*}" == "$VAR" ]]

for var in $(grep -vFe "$VARS" <<<"$(set | egrep "^\w+=")" | grep -v ^VARS=)
 do [[ "${var%%'='*}" == "$VAR" ]] && echo "Var $VAR exists in script"
done

To test this run the script and enter TEST
run the script again and enter some variable preset in the env DISPLAY, PS1, etc
You can also source some script but it will not check the variables against the env.

Perhaps something like this is needed to analyze the difference between
the env before the script was sourced, against the env after the script was sourced.

before=$(set | egrep "^\w+=")
source /home/misko/Desktop/pmrp2
diff <(echo "$before") <(set | egrep "^\w+=")

johnraff · 2017-05-14 03:42:13

ohnonot wrote:

^ and for readability, i found that the under_score really helps to make variables stand out visually. more so than camelCase, which i hate, hate, hate with a passion.

hmm so variable_name vs variableName...
Still not sure which I prefer. The underscore does require one more keystroke, but it is a bit easier on the eyes. I used to find camelCase really ugly, but it doesn't bother me quite so much these days.

ohnonot · 2017-05-14 10:43:15

example from some random config file:

i don't want to start a religion; i guess people's eyes are different.
for me the first works better.

johnraff · 2017-05-15 05:04:48

...no, I'm really not sure which I prefer...

damo · 2017-05-15 21:00:27

I much prefer camelCase to the awkward and ugly underscore (especially when it is the leading character) hmm

johnraff · 2017-05-16 01:10:31

Great! Now we can have another flame war!!
Move over emacs<>vim... cool

ohnonot · 2017-05-16 06:24:10

damo wrote:

I much prefer camelCase to the awkward and ugly underscore (especially when it is the leading character)

yeehaaah!
let the flame wars commence!
trolldance.gif?1477057420

damo · 2017-05-16 07:43:20

ohnonot wrote:

damo wrote:
I much prefer camelCase to the awkward and ugly underscore (especially when it is the leading character)
yeehaaah!
let the flame wars commence!
http://emojis.slackmojis.com/emojis/ima … 1477057420

_flameWar

johnraff · 2017-05-17 02:55:19

Linebreak in string
bash has "dollared single quotes" (see QUOTING in man bash) which let you use backslash escaped sequences. The only one I make regular use of is \n for a newline. So you don't always need to spread a string over multi lines.

Simple strings:

string='first line
second line'

can just have linebreaks put in as-is, but if you're joining variables, separated by linebreaks, it can make for a neater line sometimes:

string="$var1"$'\n'"$var2"
# as opposed to
string="$var1
$var2"

It depends on the situation, and your taste...

brontosaurusrex · 2017-05-17 08:51:04

johnraff wrote:

Great! Now we can have another flame war!!
Move over emacs<>vim...

To add a 3rd:
I don't use either, but lowercase all, example found: $halfwidth
I do use camelCase for fileNames someTimes.

Handling docx

unoconv -f text --stdout file.docx

Last edited by brontosaurusrex (2017-05-17 08:57:18)

#26 2016-01-09 03:28:12

Re: Handy command-line stuff for terminals or scripts

#27 2016-01-09 12:16:48

Re: Handy command-line stuff for terminals or scripts

#28 2016-01-10 00:34:44

Re: Handy command-line stuff for terminals or scripts

#29 2016-01-10 00:43:41

Re: Handy command-line stuff for terminals or scripts

#30 2016-01-10 02:10:48

Re: Handy command-line stuff for terminals or scripts

#31 2016-01-13 19:44:25

Re: Handy command-line stuff for terminals or scripts

#32 2016-01-25 04:46:43

Re: Handy command-line stuff for terminals or scripts

#33 2016-08-01 08:00:27

Re: Handy command-line stuff for terminals or scripts

#34 2016-08-01 08:03:14

Re: Handy command-line stuff for terminals or scripts

#35 2016-08-01 15:45:52

Re: Handy command-line stuff for terminals or scripts

#36 2017-05-12 07:01:49

Re: Handy command-line stuff for terminals or scripts

#37 2017-05-12 07:03:11

Re: Handy command-line stuff for terminals or scripts

#38 2017-05-12 18:45:19

Re: Handy command-line stuff for terminals or scripts

#39 2017-05-13 03:24:17

Re: Handy command-line stuff for terminals or scripts

#40 2017-05-13 12:07:17

Re: Handy command-line stuff for terminals or scripts

#41 2017-05-13 14:51:57

Re: Handy command-line stuff for terminals or scripts

#42 2017-05-14 03:42:13

Re: Handy command-line stuff for terminals or scripts

#43 2017-05-14 10:43:15

Re: Handy command-line stuff for terminals or scripts

#44 2017-05-15 05:04:48

Re: Handy command-line stuff for terminals or scripts

#45 2017-05-15 21:00:27

Re: Handy command-line stuff for terminals or scripts

#46 2017-05-16 01:10:31

Re: Handy command-line stuff for terminals or scripts

#47 2017-05-16 06:24:10

Re: Handy command-line stuff for terminals or scripts

#48 2017-05-16 07:43:20

Re: Handy command-line stuff for terminals or scripts

#49 2017-05-17 02:55:19

Re: Handy command-line stuff for terminals or scripts

#50 2017-05-17 08:51:04

Re: Handy command-line stuff for terminals or scripts

Board footer