You are not logged in.
^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)
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
^ 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.
Offline
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 !!.
Offline
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.
“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.
Offline
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!
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
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!
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
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!
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
This returns the size (in human readable format) of the current directories contents excluding any subdirectories.
ls -lh | head -1
Offline
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.
Offline
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
OS: Devuan & OpenBSD | WM: CWM
\m/ Ijime, Dame, Zettai「イジメ、ダメ、ゼッタイ」\m/
Offline
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.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
^ 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)
“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.
Offline
Need a script checker to check for variable collisions for not just internal variables but checks the env. variables too!
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
^Just avoid upper case and you'll be OK. All envvars are UC.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
^ 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.
Please use CODE tags for code.
Search youtube without a browser: repo | thread
BL quote proposals to this thread please.
my repos / my repos
Offline
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+=")
Што ни оштровиди ум сагледати не може - љубав превазилази.
Offline
^ 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.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
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.
Please use CODE tags for code.
Search youtube without a browser: repo | thread
BL quote proposals to this thread please.
my repos / my repos
Offline
...no, I'm really not sure which I prefer...
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
I much prefer camelCase to the awkward and ugly underscore (especially when it is the leading character)
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
Great! Now we can have another flame war!!
Move over emacs<>vim...
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
I much prefer camelCase to the awkward and ugly underscore (especially when it is the leading character)
yeehaaah!
let the flame wars commence!
Please use CODE tags for code.
Search youtube without a browser: repo | thread
BL quote proposals to this thread please.
my repos / my repos
Offline
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
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
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...
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
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.
unoconv -f text --stdout file.docx
Last edited by brontosaurusrex (2017-05-17 08:57:18)
Online