On Mon, Aug 13, 2012 at 7:13 PM, Ben Scott <[email protected]> wrote: > On Mon, Aug 13, 2012 at 6:23 PM, Kurt Buff <[email protected]> wrote: >>> foo 3>&1 1>&2 2>&3 3>&- >>> ... runs "foo" with stdout and stderr flipped. >> >> I've not run into the need to do that, and I think I'm grateful... > > Manipulating file descriptors can be useful. One particular > application is using a program like dialog(1) to capture user response > out-of-band on a file descriptor you open for that purpose, while > still giving dialog(1) a working stdout and stderr. > > exec 4>&1 > > ANSWER=$( ( dialog --output-fd 3 --inputbox 'Speak Friend and enter' > 0 0 1>&4 ) 3>&1 ) > > Granted, it's not exactly self-explanatory, but hey, this is nix > we're talking about. > >> Besides, the default shell in FreeBSD is (t)csh, and it's what I stick >> with - don't even know if you can do that in tcsh. > > Prolly not. I used to be a (t)csh user myself, and while I found > the syntax much less idiosyncratic, it's ultimately a dead end. csh > is both rather limited and rather broken, and tcsh is still somewhat > of each. Or so it was when I jumped ship to Bash, and I don't think > tcsh was being developed anymore. > > -- Ben
All good stuff. But, between sed, awk, and grep I can usually manage, and if those aren't sufficient, I'll steal a perl script from somewhere and hack it up. I've never liked bash, for some obscure reason. I suppose it's something like why I don't like linux, and prefer freebsd. Kurt ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
