On 9/26/11, Ethan Grammatikidis wrote:
> Okay. I'm a bit brain-dead this week but if I remember right:
>
> This puts stdout and stderr in the same place:
> $ foo 2>&1 | bar
>
> This puts them in different places:
> $ foo 2>&1 > file
>
Didn't rc fix this by executing file and file descriptor redire
On Mon, 26 Sep 2011 13:47:58 +
Bjartur Thorlacius wrote:
> >> rc's redirection syntax is remarkably clean and powerful, but it
> >> shouldn't be very hard to hack "2>&1" support in there if you don't want
> >> to use ">[2=1]".
> >
> > Actually I find rc's way less annoying than bash's but the
On Sun, Sep 25, 2011 at 8:38 PM, Ethan Grammatikidis
wrote:
> On Sun, 25 Sep 2011 20:17:23 +0200
> Christian Neukirchen wrote:
>
>> Ethan Grammatikidis writes:
>>
> Shell language in general, as a tool to use. It's not just cp & mv,
> there are other things.
>
cp -r and mv -r should be split int
On Sun, 25 Sep 2011 20:17:23 +0200
Christian Neukirchen wrote:
> Ethan Grammatikidis writes:
>
> > It's redirection and the behaviour of cp & mv when the last arg is a
> > dir that bother me, in rc.
>
> What has the behavior of cp and mv to do with the shell used?
Shell language in general, a
Ethan Grammatikidis writes:
> It's redirection and the behaviour of cp & mv when the last arg is a
> dir that bother me, in rc.
What has the behavior of cp and mv to do with the shell used?
rc's redirection syntax is remarkably clean and powerful, but it
shouldn't be very hard to hack "2>&1" su
