« first day (2694 days earlier)      last day (2558 days later) » 

10:56
We are tracking down the stability issues on Stack Overflow, please bear with us s we figure out what's stalling out. I have removed the currently angry servers from traffic pools while we dig.
11:29
Ah, I did experience some hiccups with U&L today...
12:16
@Kusalananda xsetroot -solid midnightblue for the longest time
@JeffSchaller Funnily enough I just noticed that I actually have a photo as my background wallpaper, but I usually never see it since I have a terminal running tmux in full-screen mode... :-)
@Kusalananda my other computer used a random slideshow from (the old?) Digital Blasphemy site. I'm in the same boat as you, though -- always full-screening or covering up 90% of the space
Oh wow, it's still up after all these years. fluorescence was one of the first I downloaded.
@JeffSchaller Oh, I remember that site. Never used it for wallpapers though.
... maybe I downloaded a few images, but I don't really remember.
 
3 hours later…
15:55
@Kusalananda Am sorry but I just need file name but not absolute path
so am using ls -1rt NBC-*
instead of glob
@overexchange You'll get the filename with basename: for name in "$sDir"/ABC-*; do filename=$( basename "$name" ); ... ; done
Just don't use ls...
Instead of $( basename "$name" ) you could also use ${name##*/}.
It is wrong to use ls in a loop, and you don't need to since the shell can easily be used to pick out the filename from the path.
16:19
ok
with that filename am doing below.. to compress files keeping the existing files unchanged
for file_name in "$sDir"/NBC-*; do name=$(basename "$file_name" ); gzip -c $sDir/$name > $sDir/$name.gz; done
It is working but
Is there a better style than gzip -c $sDir/$name > $sDir/$name.gz
Why pick out the basename there? You just need for name in "$sDir"/NBC-*; do gzip "$name"; done or just even gzip "$sDir"/NBC-*
Am doing something else also with name
gzip will always add a .gz suffix.
Well, gzip -c $sDir/$name > $sDir/$name.gz could at least be changed to gzip "$file_name"
16:26
But I need the files to get created in same folder, so making sure about paths
By default they go in same folder?
zipped files?
script can be running from someother folder
Yes, the way you wrote your loop, $file_name will contain the path to the file. gzip will create the compressed version of the file in the same directory as the original.
The only thing different between what I and what you wrote is that the uncompressed file will be deleted with my code.
I do not want to delete uncomressed file
Well, then you can still do gzip -c "$file_name" >"$file_name".gz
$file_name will contain the full path to the file.
I do not want file_name having full path
because there but only the file name
because I do also soemthign else in for loop
But you wrote: for file_name in "$sDir"/NBC-*; do name=$(basename "$file_name" ); gzip -c $sDir/$name > $sDir/$name.gz; done. In this loop, $file_name is the full path to the file.
That is the same as: for file_name in "$sDir"/NBC-*; do name=$(basename "$file_name" ); gzip -c "$file_name" > "$file_name".gz; done
16:33
Ah I understand now
Can I say sDir=/a/b;rm $sDir/*.gz
@overexchange Yes. That rm is the same as rm /a/b/*.gz.
or shall I say sDir=/a/b;rm "$sDir"/*.gz
Ah. Yes, do double-quote variables. It's a good habit.
16:48
gzip -k should keep the input file
Do I need to use double quotes in if condition as well?
sDir=/a/b/c
file_name_pattern=MNO-*

for file_name in "$sDir/XYZ-*"

do
         i=$(basename "$filename" )
         if [[ ${i} == $file_name_pattern ]]; then

		 fi
done
Inside [[ .. ]] is one of the few places you don't need double quotes
Inside [[ .. ]]
76
Q: When is double-quoting necessary?

kjoThe old advice used to be to double-quote any expression involving a $VARIABLE, at least if one wanted it to be interpreted by the shell as one single item, otherwise, any spaces in the content of $VARIABLE would throw off the shell. I understand, however, that in more recent versions of shells,...

Shall I say if [[ ${i} == ${file_name_pattern} ]]; then
17:08
Below is the script that copies all the files from /a/b/c to /d/e/f
#!/bin/bash

exec 5> ./debug_file
BASH_XTRACEFD="5"

set -x
sDir=/a/b/c
dDir=/d/e/f
rDir="$dDir/recent"

mkdir -p $sDir
mkdir -p $dDir
mkdir -p $rDir

# Delete existing zip files, if any
rm "$sDir"/*.gz 2> /dev/null

file_name_pattern=NBC-*

for file_name in "$sDir/NBC-*"

do
         i=$(basename "$filename" )
         if [[ ${i} == $file_name_pattern ]]; then

                echo "Processing file ${i} ...."

                deviceName=`echo $i | cut -d '_' -f1`
                prefix=`echo ${deviceName:0:3}`
But I do not see working
I do not see [[ ${?} = 0 ]] working as well
shellcheck.net might mention some issues
But wildcards don't work when quoted, so "$sDir/NBC-*"will leave a literal asterisk. You'll need the wildcard part outside quotes, as in "$sDir/NBC"-*
I don't see any reason why [[ ${?} = 0 ]] shouldn't work, but you could just write if gzip .. ; then mv ... etc. Checking the return status is what if does. But shellcheck does mention both of these points. :)
or for file_name in "$sDir"/NBC-* this shoudl also be fine?
I did not get the meaning of ${?} = 0
yeah, everything in /NBC- is just normal characters, so it doesn't matter if that part's quoted or not
What are we doing in [[ ${?} =0 ]]?
$? is the return value of the previous command. The rest is a comparison. BashGuide has a page on tests and conditionals... mywiki.wooledge.org/BashGuide/TestsAndConditionals
17:31
But shellcheck asks to quote
@overexchange You can drop if [[ ${i} == $file_name_pattern ]]; then. It is guaranteed that $i will be a filename matching the pattern NBC-*. What you could do (at the start of the script) is shopt -s nullglob so that globs against non-existing files returns nothing.
ok
shopt -s nullglob at first line of script?
What does it do?
nullglob
If set, Bash allows filename patterns which match no files to expand to a null string, rather than themselves.
I have been thru shellcheck, for below script
#!/bin/bash

exec 5> ./debug_file
BASH_XTRACEFD="5"

set -x
sDir=/a/b/c
dDir=/d/e/f
rDir="$dDir/recent"

mkdir -p $sDir
mkdir -p $dDir
mkdir -p $rDir

# I1817157 - start
# Delete existing zip files, if any
shopt -s nullglob
rm "$sDir"/*.gz 2> /dev/null

# I1817157 - end

# regexp="^[A-Z0-9]{3}-[A-Z]{8}-[A-Z]{2}[0-9]{3}-[A-Z]{3}[0-9]{2}-[A-Z0-9]{3}$"

for file_name in "$sDir"/NBC-*

do
         i=$(basename "$filename" )
         echo "Processing file ${i} ...."
         deviceName=`echo $i | cut -d '_' -f1`
I got below errors
Line 27:
i=$(basename "$filename" )
^-- SC2154: filename is referenced but not assigned (did you mean 'file_name'?).

Line 29:
deviceName=`echo $i | cut -d '_' -f1`
^-- SC2006: Use $(..) instead of legacy `..`.
^-- SC2086: Double quote to prevent globbing and word splitting.

Line 30:
prefix=`echo ${deviceName:0:3}`
^-- SC2006: Use $(..) instead of legacy `..`.
^-- SC2116: Useless echo? Instead of 'cmd $(echo foo)', just use 'cmd foo'.
^-- SC2086: Double quote to prevent globbing and word splitting.
file_name
resolved first ero
17:59
SC2006 is telling you to write $(command) instead of `command`
SC2086 is telling you to write echo "$i" instead of echo $i
SC2116 is telling you that foo=$(echo bar) is better written foo=bar
@overexchange see above, but really questions ought to go on the site
For
Line 29:
deviceName=`echo $i | cut -d '_' -f1`
^-- SC2006: Use $(..) instead of legacy `..`.
^-- SC2086: Double quote to prevent globbing and word splitting.
Shal I say deviceName=$(echo $i | cut -d '_' -f1)
@overexchange deviceName="$(echo "$i" | cut -d '_' -f1)" probably, though I think the outermost set of quotation marks is optional since its an assignment
@derobert That is correct.
although bash probably has a way to do that without cut
actually, deviceName=${i%%_*} should do
18:13
Yes
Delete everything after the first _.
Would it be enough with a single %?
Probably.
No
@overexchange BTW: looks like shellcheck somes with explanations, see for example github.com/koalaman/shellcheck/wiki/SC2006
rm $rDir/$deviceName* ======> rm "$rDir/$deviceName*"
for
Line 37:
rm $rDir/$deviceName*
^-- SC2086: Double quote to prevent globbing and word splitting.
ah github says, When quoting composite arguments, make sure to exclude globs and brace expansions, which lose their special meaning in double quotes: "$HOME/$dir/src/*.c" will not expand, but "$HOME/$dir/src"/*.c will.
18:29
yes, without the quotes any wildcards inside the variables would also expand, and that's usually not what people want (and has surprising results because it also results in multiple words). mywiki.wooledge.org/WordSplitting if you already haven't seen that
So, rm $rDir/$deviceName* ======> rm "$rDir/$deviceName"*
Same as the "$sDir"/NBC-* one
howdy!
deviceName=`echo $i | cut -d '_' -f1`     ====>     deviceName="$(echo "$i" | cut -d '_' -f1)"
prefix=`echo ${deviceName:0:3}`           =====>    prefix="$(echo "${deviceName:0:3}")"
mkdir -p $dDir/$prefix/$deviceName/	 ======>   mkdir -p "$dDir/$prefix/$deviceName/"
rm $rDir/$deviceName*			  ======>   rm "$rDir/$deviceName"*
chmod 644 $sDir/$i		======> chmod 644 "$sDir/$i"
cp $sDir/$i $rDir/      ======>  cp "$sDir/$i" "$rDir/"
if [[ ${?} = 0 ]]; then  ======>  if gzip -c "$sDir/$i" > "$sDir/$i".gz; then
these are the changes based of shell check
18:40
quick question if anyone cares to answer. I'm using grep -e and I'm getting a command not found error. my code is:
grep -e '\<_'|'a-z'
@Jordan That's two commands in a pipeline. The second command is a-z.
The command not found is a-z, I was under the impression that anything inside quotes while grepping should be a regex command right?
@Jordan The quote ends at _.
That should be -e not -g
Sorry, the changes are..
deviceName=`echo $i | cut -d '_' -f1`     ====>     deviceName="$(echo "$i" | cut -d '_' -f1)"
prefix=`echo ${deviceName:0:3}`   =====>    prefix="$(echo "${deviceName:0:3}")"
mkdir -p $dDir/$prefix/$deviceName/	  ======>   mkdir -p "$dDir/$prefix/$deviceName/"
rm $rDir/$deviceName*	  ======>   rm "$rDir/$deviceName"*
chmod 644 $sDir/$i		======> chmod 644 "$sDir/$i"
cp $sDir/$i $rDir/     ======>  cp "$sDir/$i" "$rDir/"
if [[ ${?} = 0 ]]; then  ======>  if gzip -c "$sDir/$i" > "$sDir/$i".gz; then
Any quick comments?
18:43
@Jordan '\<_' is the quoted part
@Jordan You probably want grep -E '\<_|[a-z]' or something similar depending on what you're doing.
Thanks guys ^^ I'll keep hacking away at it
@o prefix=${deviceName:0:3} doesn't need a round-trip through the command substitution
Yup that gets me somewhere. thanks again
@Jordan Note that _ is also a "word character", so no need to handle it specially at beginning of words.
18:44
@Jordan if you need to include a single-quote inside the string, the easiest way is to use a double-quoted string if possible: "includes ' single quote"
Though if you need to include a backslash, then single quotes are easier...
if that doesn't work.. 'includes '\'' single quote'
I just needed to include that _ specifically because the set that I'm using it for also contains "@, !, $" as beginning of words and I just want the "_'s"
that works by closing the single quote, \' gives a single quote, then start a new single-quote string
Ive also read that I should use quotation marks and not parenthesis for Regex in unix. Is that true?
18:46
errr..
quotes and parens don't do even nearly the same thing
oh, i must've misread
Depends on context I suppose. Though I've never seen parens used to delimit regexes.
There are two levels of quoting/escaping going on — one of them is to protect the regex from the shell. Then there are escapes inside the regex itself, to e.g., make \$ match a literal $ (instead of end-of-string/line)
in Perl you could delimit a regex with something like m(pattern) or s(foo){bar}
yes, grep doesn't do that. It doesn't have a delimiter, it's the entire argument.
18:48
And sed has the toothpicks.
though in sed you can choose the delimiter... so sed -e 's(foo(bar(' works. :D
... as does awk.
@ilkkachu but different than perl, which would want s(foo)(bar) because Perl knows parens (and braces, and brackets) are supposed to open and close :-)
yes.
@ilkkachu That's bound to throw any syntax highlighter into orbit. (unless it does proper parsing)
18:50
yes. :) (hence the smiley)
perl is unparsable, so you get used to perl syntax highlighters breaking randomly.
Actually, I'm still waiting for Vim to properly support Bash/ksh syntax for arrays properly.
(it may actually do that already, and I'm thinking of something else)
19:41
For command rm $rDir/$deviceName* I get missing operands. I know i did not use quotes but..
this should work
19:57
echoing that gives nothing
 
4 hours later…
cas
cas
23:37
@derobert /usr/bin/perl disagrees :)
SE's syntax highlighter breaks on perl all the time, even on simple s/..../...../
i usually "fix" that by adding a comment with a / in it.

« first day (2694 days earlier)      last day (2558 days later) »