Reputation
486
Top tag
Next privilege 500 Rep.
Access review queues
Badges
2 5
Newest
 Yearling
Impact
~10k people reached

  • 0 posts edited
  • 1 helpful flag
  • 18 votes cast
1d
comment Bash parameter expanstion to remove tabs
@MateuszPacek In the output from cat -vet, $ means linefeed, and that's added by echo so you should ignore it. from the output, that's not a tab at all, it's just a space. But if you do a global removal of blanks (//[[:blank:]]/), it should be removing the space in the middle as well (i.e. "ONLINESLAVE"), so I'm really confused what's going on here.
2d
comment Bash parameter expanstion to remove tabs
@MateuszPacek It sounds like there's something other than tabs in the string (sequences of spaces?) that [[:blank:]] is matching but $'\t' isn't. Try examining the string with echo "$PARAMVAR" | LC_ALL=C cat -vet -- that should show tabs as "^I", and spaces just as spaces. As for documentation, you have to look at the "3.5.3 Shell Parameter Expansion" and "3.5.8.1 Pattern Matching" sections; also, check BashFAQ #100: How do I do string manipulations in bash?.
2d
answered Bash parameter expanstion to remove tabs
Aug
24
comment in bash script; a process stdout as filename argument fails when you open it more than one time
@MostafaNazari It's not a bug (and actually doesn't have anything to do with bash), it's just the way pipes work. When you read from a pipe (e.g. with the first cat), the data you read is removed the from the pipe -- there's just no way to go back and read it again, because the data isn't there anymore. That's why the second cat didn't get anything.
Aug
24
comment in bash script; a process stdout as filename argument fails when you open it more than one time
Wow, you're right; I though I'd tested that before commenting, but apparently not...
Aug
23
answered in bash script; a process stdout as filename argument fails when you open it more than one time
Aug
23
comment in bash script; a process stdout as filename argument fails when you open it more than one time
<<< doesn't give you a regular file either, it uses a pipe. If you want a regular, seekable file, you have to create one. Or avoid trying to read the file twice.
Apr
7
comment About executing shell script
Note that back when Kernighan&Pike was written, it was common to have the current directory (".") in the PATH (meaning that foo.sh would work without the ./). This was a found to be a security problem (someone could leave e.g. a malicious script named "ls" in their directory, then trick other people into running it), so it's no longer common (or recommended) practice.
Mar
24
comment Why doesn't $@ work when passing strings?
@orangeorange You can't safely store multiple arguments in a plain variable. But you can store them in an array with t=("$@"), and then reference it as "${t[@]}" to recover the original argument list intact. Note that all of the double-quotes I used are necessary.
Jan
20
awarded  Yearling
Jan
20
answered Quoting / escaping / expansion issue in “command in a variable”
Jan
4
awarded  Citizen Patrol
Nov
24
comment How can variables use “~” for cd'ing?
@hvd: you actually have to leave the slash unquoted as well. BASE=~/"quoted name" works, but BASE=~"/quoted name" doesn't.
Nov
10
comment Emulating /etc/cron.d/ on OSX
Ah, I misunderstood; in that case, the answer is that OS X's version of cron doesn't have that feature. But actually, I'd argue that since you'd have to do it differently on OS X anyway (adding a line to /etc/crontab rather than dropping a file in /etc/cron.d), you might as well go all the way and drop a file in /Library/LaunchDaemons instead.
Nov
10
answered Emulating /etc/cron.d/ on OSX
Jul
24
comment bash script loses readonly value after first time thru loop
If double-quotes around the array reference are causing trouble, I'm pretty sure there's something wrong with how the array is being constructed; removing the double-quotes should not be necessary. I'd concentrate on figuring out what's building the array wrong.
Jul
2
answered Piping content with multiple spaces
Jun
26
answered user input not accepted in nested case statement
Jun
17
comment How Does Linux deal with shell scripts?
This behavior is version-dependent. I tested with bash version 3.2.51(1)-release, and found that it didn't buffer past the current line (see this stackoverflow answer).
Jun
15
awarded  Commentator