| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8
Comments:
<0> most people find the manual cryptic.
<1> i read the bash man page with pleasure always. but sometimes i prefer the faq, even it just appends information to what i already know
<2> bash manpage has one important sentence regarding redirection: "from left to right"
<2> i don't know what's actually difficult there (for you)
<1> greycat, #55 is excellent, good explanation
<1> TheBonsai, don't know, i guess i needed it explained as in #55 (redirection for dummies ;)
<1> the crucial thing i get now is that 2>&1 >/dev/null means: "redirect stderr to where stdout is pointed NOW"
<1> and then redirect stdout to /dev/null
<1> like you said "from left to right", i guess i needed a more wordy explanation
<1> i think the most common misconception causing people to wonder about redirect is because they think both redirections are like 'options' to bash, where bash is expected to be aware of stdout >/dev/null at the moment it parses 2>&1
<0> in my experience, it's *extremely* common for people to somehow ***ume that 2>&1 means the two FDs are somehow "united", and that therefore any subsequent redirections affect both
<1> yes
<1> exactly
<3> even though the manual specifically says otherwise.
<2> manpage even has an example, just found it
<3> complete with an example of getting it wrong and getting it right.
<2> yea
<2> where bash's manpage usually has no examples at all
<0> also, we can give a precise URL to an explanation -- we can't give a URL to the right paragraph of the man page.
<0> telling people to "search for foo in the man page, then jump down 2 paragraphs, then ...." is a losing battle.
<1> another misconception exists that program authors are good at writing manuals for people who start out with no knowledge whatsoever.
<4> locsmif: a manual page is more of a reference, not a tutorial
<1> heiner, yes
<2> greycat: anyways, bash manpage ****s for new users. it's nearly unreadable the first time
<1> i like the bash manpage, i just don't rely on it exclusively
<0> that's why we have the FAQ and other resources
<5> xterm -bg black -fg white +tb -fn -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1 for the win!
<5> oops sorry, wrong chan
<6> horrible font :(
<5> yes?`you use terminus then i'd ***ume?
<6> gamow alt
<6> different ones, i like lfpfonts
<5> hmm.. gamow good for coding large bash scripts? :P
<6> i like it :)
<5> ok, i'll try it...
<0> "good" and "large bash scripts" cannot peacefully coexist in the same sentence.
<5> hehe
<6> :)
<7> what's the easiest or standard (Y/n) check in bash ?
<7> before I fabricate something awfull myself
<6> help test
<1> rhalff, case
<7> locsmif, are you sure you wanna do this ? (Y/n) where Y is default and n, NO, no, neh is no.
<1> read -s -n 1; case $REPLY in y|Y) echo yes;; n|N) echo no;; esac
<7> ok the | is handy
<8> whats wrong with this? if [ "$leftcode" != "" && "$rightcode" == "" ]; then
<1> read -p "Hand me the keys!"$'\n' -s -n 1; case $REPLY in y|Y) echo yes;; n|N) echo no;; esac
<8> i keep getting "./parse_out: line 22: [: missing `]'"
<1> gnychis, &&
<1> use -a
<4> gnychis: use [[ ...]] instead of [...]
<8> cool, thanks
<1> gnychis, if you use [[ .. ]] no need to quote around variables anymore
<7> locsmif, how to make this work ? if [ yes == (''|Y|Yes) ]
<7> :)
<1> rhalff, **** that, i gave you a much better solution
<3> rhalff: if you insist on using [ then you must work harder.
<7> ok I'll work harder then
<3> even with [[ you'd need a glob. (instead of the mess you tried)
<7> ok, I'll do the switch then
<7> anyways that switch will just continue when I say, asdfasd or not ?
<3> "that" switch? which is the one you mean?
<8> i ***ign things in an array within a while loop, once after the "done" in the while loop, the variable seems to be reset and i lose its values, as if it were local only to the while loop, how can i initialize it outside the while loop so it is not local?
<7> read -p "Hand me the keys!"$'\n' -s -n 1; case $REPLY in y|Y) echo yes;; n|N) echo no;; esac
<3> your if [ yes == ... thing? won't do anything useful.
<3> ahh, locsmif's case. it should do something useful.
<3> it won't "loop back" if they respond other than y or n -- if you want that, make a loop.
<7> but what will that do in case of not n|N|y|Y ?
<3> gnychis: pipelines run in sub-shells
<3> rhalff: it will echo yes or no depending which letter you typed.
<8> twkm: oh... so i need to export it?
<3> gnychis: uh.
<3> gnychis: i suppose you can. it won't change the outcome though.
<8> twkm: is there any way to do it then?
<3> gnychis: don't use a pipeline.
<8> twkm: whats another way to do this then: less $IN_FILE | grep -v "^Start" | awk '{if (NF == 11) print}' | while read line; do
<4> gnychis: do you use a pipeline, or redirect input from a file?
<4> gnychis: that answers my question
<8> heh
<8> so is there another way to do it?
<4> gnychis: the interesting part is what comes after "while read"
<8> heiner: http://rafb.net/paste/results/vjEDig45.html
<3> less at the beginning of a pipeline?!?!?!
<3> holy ****.
<8> its gzip'ed text
<3> so?
<4> gnychis: please use "cat" to print the contents of a file
<8> twkm: so... zcat ? i don't get the difference
<3> *shrug*
<6> zgrep...
<4> gnychis: "less" is no standard command, and tries to be clever with handling the terminal. This is not required here
<4> in fact it could cause harm
<8> alright
<8> i'll cut the first part out and use zgrep
<3> anyway, while read line; do ...; done < <(whatevercraphere | awk )
<8> twkm: thanks
<4> gnychis: an example of a *_blinc file would help
<8> i don't really need help with the parsing, just the array problem
<8> what twkm said solved my problem, so all is good now
<4> My idea is to replace the complete "while read line" loop with one AWK program
<8> heiner: i'll stick to what i know, or think i know :)
<1> write it in Cobol :P
<4> gnychis: some comments: the pipeline before the "while" can be replaced with awk '$1 != "Start" && NF == 11' "$IN_FILE" | ...
<4> gnychis: the calculation of the sum can be shortened to echo "$line" | awk '{print $9+$10}'
<4> the part that sets "$code" can be shortened to code=${leftcode:-$rightcode}
<4> I cannot tell about the *_blinc part
<8> cool feedback
<4> gnychis: instead of setting the variables leftip/leftport etc. you could directly construct a search pattern for the "grep" later on (in the mysterious *_blinc), by replacing the last "." with a TAB
<4> gnychis: and by replacing the complete loop with an AWK program you could speed up the script by a factor of 10-100, depending on the number of lines in $IN_FILE
<8> heiner: i wish the people who formatted the file would have thought of that :( I have about 500GB of compressed data with format IP.PORT
<4> gnychis: in that case the speed advantages could be worth doing it
<8> heiner: lines per file is about 1837933 ... and about 25274 files
<8> heiner: would you like to help? :)
<4> gnychis: no, now I'm huffy
<4> ;-)
<8> heh
<4> gnychis: the key are the _blinc files. If there is a way to read them *once* in an AWK program, processing could be sped up easily
<8> heiner: a blinc file looks like this: http://rafb.net/paste/results/n6KPmN90.html
<8> except on the order of 20000 lines each
<4> gnychis: but there's only one _blinc file for each input file, isn't there?
<8> heiner: correct
<9> why won't echo path/to/foo | xargs cd" work?
<6> heh
<9> (trying to use pbpaste from mac os x to do something ... )
<6> why not cd path/to/foo ?
<9> goldfish: i'm trying to use pbpaste | xargs cd, which will take contents of clipboard and echo it.
<6> ok.
<9> (i wouldn't be THAT silly.)
<6> cd $(pbpaste)
<6> possibly.
<0> xargs is a child process.
<9> goldfish: ah, a good idea.
<9> goldfish: such a better method. thanks.
<9> greycat: thanks.
<0> anything the child does in its private environment space (like changing dir) won't affect *you*
<0> furthermore, any command in a pipeline is a child process.
<9> greycat: thanks for the education very much.
<4> gnychis: do you have an example input file to test my script?
<9> appreciate the help.
<4> gnychis: in that case I could help debugging it. Otherwise you'll be on your own ;-)
<10> how do i check if the output of grep xzy file.txt is null in a if statement ?
<6> if grep -q xzy file.txt; then .....#not null; else ...........#null; fi
<10> thanks goldfish
<4> codeshepherd: just check if "grep" returned no error: if grep "$something" "$file"; then echo found!; else echo "not found!"; fi
<4> gnychis: here is an untested example that (when finally running) should speed up processing: http://rafb.net/paste/results/OUy9Ko88.html
<4> gnychis: remove the comments from the "zcat" line
<4> mmhm, fresh coconut
<8> heiner: muccchhhh faster... i am not sure what this means though, after i run it: "WARNING: no code found: port/ort"
<11> Does anyone have a bandwidth monitoring script written in bash? I wrote something that counts deltas from the TX and RX values taken from /proc/net/dev, but I don't see the results as too realistic.
<4> gnychis: some ipaddr.port pair has not been found in the _blinc file
<11> Perhaps you come up with some other idea I can implement?
Return to
#bash
or
Go to some related
logs:
#perl
gaim auto-away status back
#kde
mplayer full screeen
gpg import secring
#php
117f is celsius
#fedora
#perl
#perl
|
|