1,463 reputation
415
bio website
location
age
visits member for 2 years, 6 months
seen 4 hours ago

1d
comment Syntax Error: unexpected end of file — Bash script
(Cont’d) …  Once the error goes away, put the last lines you deleted back in, and start whittling away at them.   For example, if deleting lines 157-174 does make the error go away, put them back in, but then delete lines 159-160, 163-168, and 171-172.   Try replacing the `grep …` with a list of values.   In other words, use the process of elimination.
1d
comment Syntax Error: unexpected end of file — Bash script
Here’s a debugging approach: Try deleting lines 157-174 and running the script again.   If you still get the error (probably reported as being at line 157 or 158), then you know the problem isn’t in lines 157-174, and you have to look further back (so, repeat the process until the error goes away).  … (Cont’d)
1d
comment Syntax Error: unexpected end of file — Bash script
(Cont’d) …  (2) You should always quote shell variables unless you have a good reason not to and you’re sure you know what you’re doing; e.g., "$1", "$2", "$SECONDS", and "$starttime".  (3) It’s easier to read and debug code that’s indented properly.  (4) Why are you setting FS and then not using it?  (5) `…` can be written $(…).  (6) $(($SECONDS - $starttime)) can equivalently be written $((SECONDS - starttime)).  Again, this is basically an issue of style.  (7) Why are you printing "$words_read" in the loop when you aren’t modifying it in the loop?
1d
comment Syntax Error: unexpected end of file — Bash script
(0) It might have been more useful to show us a diff from the last version that worked. … … … … … … … … Some observations (that probably don’t relate to your current, specific problem): (1) I don’t know of any circumstance where you need an unescaped ; (semicolon) at the end of a line.  You can delete the semicolons at the ends of lines 157, 161, 165, 168, and 169.  (Or you can leave them in; I guess it’s a question of style.)  … (Cont’d)
Mar
27
comment Is it possible to get static backreference with grep?
@steeldriver: That sounds like a bug to me (or, alternatively, bad documentation). What do you think?
Mar
27
comment Is it possible to get static backreference with grep?
What's wrong with this?
Mar
27
revised Is it possible to get static backreference with grep?
Second try.
Mar
27
answered Is it possible to get static backreference with grep?
Mar
27
comment Is it possible to get static backreference with grep?
Oh, you want the entire input file displayed, but you have grep aliased to grep --color, and you want the groups of four lines that match your regex to be highlighted in color! It sure would have been nice if you’d mentioned that in your question!
Mar
27
comment Is it possible to get static backreference with grep?
When I run your command on your data, I get the entire file. What are you getting?
Mar
27
comment Is there any disadvantage of executing a shell script using nohup?
What do you mean by "this is not a UNIX / LINUX inbuilt command"? nohup has been part of Unix for four decades. Do you mean that it's not builtin to the shell? … … … … … … And what's the deal with the ALT and Enter? … … … … And what does this question have to do with Oracle VM Server?
Mar
27
comment Is it possible to get static backreference with grep?
Can you please (1) explain (in the question, not as a comment!) better what you are trying to accomplish, and post (2) a sample input, where the above command does something close to that you want, (3) the output you want, and (4) the output you're getting?
Mar
27
comment Combine lines of file to string
No, seriously; what does the input look like?
Mar
27
comment Does the inode change when renaming or moving a file?
Checking access time will lead to false positives; checking size will lead to false negatives. To check whether a file has been modified (its contents have been altered), look at mtime. To see whether any aspect of a file (contents or attributes) have changed, use ctime.
Mar
27
answered Does the inode change when renaming or moving a file?
Mar
26
comment `command .*` acts on the parent directory
Related: Does 'rm .*' ever delete the parent directory? rm specifically protects against this; commands like chmod and chown do not.
Mar
26
comment Convert file pattern in Unix
Other possible building blocks include awk, while read, printf, ....
Mar
26
comment Simple flag based comparison in Linux
You say, “This assumes that your variable is always set to either true or false.” That statement deserves more attention. If this script will ever be run by anybody other than the author, you have to really make sure that $FLAG_Control is never set to anything other than true or false; i.e., that the user cannot manipulate the script into setting it to something like rm * (i.e., this becomes a security / input validation issue). I suggest that string comparison is safer.
Mar
26
comment Simple flag based comparison in Linux
I doubt that techiebong meant to execute false as a command; I suspect that he thought he was just evaluating it as a Boolean value. But this is one way to get the script to work.
Mar
26
comment Simple flag based comparison in Linux
Allan: While enclosing variables in braces is often important, it is not equivalent to quoting them, which is even more important. E.g., "$foo" and ${foo} are both better than $foo, but "${foo}" may be even better than either. … … @dhag: I suspect that Allan is thinking that the options are FLAG_Control=1 and FLAG_Control= (i.e., null); but, of course, he would need to say [ "$FLAG_Control" ] to make that work.