On 8/22/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > On Tue, Aug 22, 2006 at 03:02:27PM +0200, Axel Liljencrantz wrote: > > >2>&1 only redirects to a file but not to a pipe. > > > My interpretatin of this is that are doing something like > > foo 2>&1 | bar > > yes. > > > adding '2>&1' to any part of the job will result in stderr > > of _all_ processes in the pipeline > > that would be fine. > > > And this happens at the level above pipes, so all stderrs will in fact > > be redirected to the standard out of the last process in the job, i.e. > > to the screen. > > aha, i guess this makes sense. > > > The simple way to do what I'm guessing you want to do is > > foo 2>| bar > > no. > that one is clear. > > what i want is to combine pike 1 and 2 into one pipe which i then > redirect as a combination.
Oh, yes that makes sense as well. > > > begin; foo 2>&1; end | bar > > this does what i need, thanks. Though it is a bit ugly. I guess this is an argument for proecess level IO redirections. > > > foo 2>| bar > > this will only give me pipe 2, not both > > > I simply though IO was something that is much more intuitive to think > > about at the job-level. For example, it is not uncommon for me to > > wish to redirect stderr of _all_ processes in a job to a file > > yes i agree, except for the last pipe. > just as much os i often want to redirect output of all processes to a > file, i also want to redirect the same output through less. > that means this thinking applies to all processes but the last. I can see how that would be useful. Unfortunatly, the behaviour of redirecting all but the last process, while somewhat common, is probably not a good choice for the default IO redirection level. > > > there is a chance that fish will be changed to use per-process IO > > redirection in the future if enough people give enough good arguments > > why this is better. > > one thing that would indeed be better is to use some different syntax > element for the current IO redirection to avoid confusion. > basicly, syntax elements that look the same as in posix shell, should > also behave like that. (i don't think that is being violated anywhere > else in fish) That is indeed a very sound argument. I am however completely convinced that having two separate IO redirection systems is a bad idea, so if <> is used for process-level redirection, then job level redirection will be dropped. This, to me, is only a minor issue either way, since both operations can easily be expressed in terms of the other using blocks. > > > >ctrl-c in the tab pager only kills the pager, but not the output being > > > paged, so that the output now scrolls accross the terminal... > > If you are seeing more > > completions printed to the screen after hitting ^C then this is a bug > > that's what i am getting. > > > that I can't reproduce on my (fedora) system. If so, is there any > > additional information you can provide me with to help track this > > down? > > ugh, what kind of information could that be? > i tested this in screen, in xterm and in the console. > > any specific tests or settings i could run for this? > Try to use the fish_pager command and see if you can reproduce the behaviour when invoking it manually: fish_pager 0 "" foo bar baz The first argument should be '0', the second is the prefix shown before each completion. The rest are completions. > > > >ctrl-c and ctrl-u do not clear the commandline as they should but > > > are simply ignored. > > These work for me under Fedora. I not that these two keybindings are > > among the ones that are defined in /etc/fish_inputrc. Is it possible > > that this file is not read on startup? > > yes. > > > Specifically, what is the value > > of the $INPUTRC variable, and what is the contents of said file? > > it was missing a > $include /etc/fish_inputrc > once i added that, things started working again, sorry for the > confusion. > > i suspect this is because inputrc is following readline which only > handles one file and not a path. > > in relation to fish which generally has paths for files and does not > allow you to screw up by forgetting an include this seems a bit > counterintuitive. i don't know if this could be changed without patching > the readline library itself... Fish doesn't use the readline library, it only understands readline files. The main reason for this is that readline doesn't support syntax highlighting. But the fact that it can't be called recursively wiuthout a huge effort is also a problem, since I want the interface for the 'read' builtin to be nice. Compare the editing facilities you get in fish vs. bash when doing 'read foo'. > > greetings, martin. > -- > cooperative communication with sTeam - caudium, pike, roxen and unix > offering: programming, training and administration - anywhere in the world > -- > pike programmer travelling and working in europe open-steam.org > unix system- bahai.or.at iaeste.(tuwien.ac|or).at > administrator (caudium|gotpike).org is.schon.org > Martin Bähr http://www.iaeste.or.at/~mbaehr/ > -- Axel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
