Search:

Hi,


$ x="MARK 1 text<br> text <br> text MARK 2<br> text<br> text <br> text.<br>"
$ echo "$x" | sed -r ':a;s/^(.*MARK 2.*)<br>/\1/;ta'
MARK 1 text<br> text <br> text MARK 2 text text text....

any of these:

sed 's/ \+/,/g'
sed -r 's/ +/,/g'
sed 's/[[:space:]]\+/,/g'
sed -r 's/[[:space:]]+/,/g'

Hi,
I would suggest you always put qotes around your sed expressions unless they are trivially simple, otherwise you risk the shell's processing of your line interfering with what you want to pass...

another variation:

$ sed -n '/^\s*$/d;/^\s*--/d;1h;1!H;${x;s/\n/ /g;p}' test
this is line1 next line2 line3 then line5 last ;

@tdyboc, the reason you had trouble doing this in one sed...

Hi,
your understanding of the pattern is correct.


0,/pattern/p

says to print lines from the start of the file up to the first line that matches the pattern.

in short, its printing the...

i've just noticed sisco's new profile pic, and now yours too nothingspecial, hmm, did i miss out on a recent cat-in-clothes meme? :)

@lisati, you must be my long lost cousin from NZ :)

check out stat

e.g.
stat /some/path
To pick out the permissions, something like:

perms==$(stat /some/path | sed -n '/^Access: (/{s/Access: (\([0-9]\+\).*$/\1/;p}')
if [[ $perms =~ 777 ]];...

Don't do that. Create 1 script that checks if a user is logged in, and use that script in your cron entry.

e.g.
create a script called loggedin

#!/bin/bash
who | grep -q $1


then your...

when you grep for multiple patterns at a time grep reads each line once and checks all the patterns against that line before moving on to the next line. So you can't get the behaviour you want using...

Hi,
an individual users crontab (including root's) does not have a user field, unlike the system-level crontabs. So take out 'root' from each of your cron lines and try again.

Yes, cron runs jobs for users regardless of whether or not they are logged in. Thats one of the key features of cron actually ... the ability to run jobs unattended. As long as the PC is on, and...

I'd never thought about it before, but what a strange idiom that is ... what are these several ways, and why do we need to skin cats anyway? :)

Hi, capture the output of the job to a file so that you can see what errors are reported. there are a variety of reasons why jobs may fail under cron, so rather than guess which particular ones are...

Hi, so you just want to uncomment those lines then, rather than make other changes to them?

if so, tell sed to do something on a range of lines, starting when it matches the # enable bash...etc...

ok good. Certainly mlocate would be a likely candidate -- as it updates its index of all local filesystems.

Ok, nothing strange there. We can definitely discount the php5 job as an issue since in fact its not even being run by cron.daily, instead its an entry in /etc/cron.d, and it gets run twice an hour...

grep -or "your phrase" .
seems like a good start, like Vaphell says, unless the phrase varies line by line and you therefore need to match on a subset of the phrase.

Hi,
the last command in the log before the hang is pretty innocuous:


[ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin ...

ah yes, you're running ls within a subshell so the fact that you are setting shopt -s nullglob in the parent has no effect unfortunately.

so plan B :) , throw away the ls error output:

i=$(ls...

interesting. I think I understand now. you're running fish as your interactive shell. It has a builtin count command, the only shell I know that does.

your script however has a shebang of...

its not telling you that its not finding avi files, its telling you that it can't find the 'count' command :)

I've never heard of a count command like this either actually. you say it works from...

as gmargo says, $( ...) or ` ... ` for running commands and capturing their output. $' ... ' is a different construct in bash.
from man bash:

Words of the form $'string' are treated...

Hi,
capture stdout & stderr output from the job to a log file and inspect it afterwards for errors.
ie. amend you cron definition like so:
* * * * * /path/to/yourjob >> /path/to/logfile 2>&1

yes, ls *{word1,word2}* would expand to:
ls *word1* *word2*
which will give equivalent results in this case (and without needing extglob set)

there are other extglob patterns that you wouldn't...