Why use > at beginning of command line

[MicrosoftIsKillingMe]

@aGerman does that here. That's the first time I've seen it in that sequence, and I can't find it documented.

I suppose I am wondering what is the difference between
echo > a.txt
which is how I always thought redirection was done, and
> a.txt echo
which seems to yield similar or identical results in my tests. (All I can imagine is that it might save a pair of parentheses when using something more complex than just echo)

[aGerman]

1) Single digits are treated as stream specifiers (0 for StdIn, 1 for StdOut, 2 for StdErr, 3-9 for user-defined streams).

Code: Select all

echo 1>"test.txt"

redirects Echo is off to the file.

Code: Select all

echo 1 >"test.txt"

redirects 1 to the file plus the trailing space between 1 and >.

Code: Select all

>"test.txt" echo 1

redirects only the 1 to the file as expected.

2) It improves the readability of the code.

Code: Select all

echo Hello!>"test.txt"
echo That's just a test.>>"test.txt"
echo Bye>>"test.txt"

vs.

Code: Select all

 >"test.txt" echo Hello!
>>"test.txt" echo That's just a test.
>>"test.txt" echo Bye

Steffen

[MicrosoftIsKillingMe]

Thank you. That makes sense and your explanation is very logical to follow, and contains information I did not know.

For readability I sometimes use whitespace to align commands, like (if this shows up the same for you as it does for me on the forum post)

Code: Select all

echo 1        >  foo
echo 12345678 >> foo

but as you point out, when doing this with echo, those extras blanks are undesirably redirected! So I should consider the rearranged way (or use parentheses) instead.

(EDIT it's not showing up correctly because the forum is eating whitespace. There are 7 additional spaces after the 1 in the first echo shown, and another space after the single >, which in a nonproportional font display would have lined up nicely, although with the issue of echo not treating them as whitespace.)

[aGerman]

(EDIT it's not showing up correctly because the forum is eating whitespace. ...

Which is the reason why you should use code tags (the </> button in the editor box).

Steffen

[MicrosoftIsKillingMe]

Sorry - I only avoided them because I incorrectly thought that the code tags would eat whitespace, instead of the other way around. (I think some types of code tags on programming forums do that, anyway.) No excuse though - all I had to do was try it with Preview. Thanks for the fix. (Actually, the non-tagged DID look correct in preview, though, thus my EDIT remark )

[elzooilogico]

just a side note, any time a redirection is used within a block, the system opens and closes the file (or stream).

Code: Select all

for %%I in .... (
  >>"somefile.txt" echo %%I
)

but

Code: Select all

>>"somefile.txt" (
  for %%I in .... (
    echo %%I
  )
)

Opens the file/stream, processes all commands in the block, and then close the file/stream, so the file is opened and closed only once. This may improve performance, specially with large files.

BTW

Code: Select all

>>"%LOGFILE%" (
  ...
  ...
)

is the same as

Code: Select all

(
  ...
  ...
)>>"%LOGFILE%"

Some people prefer the first one for input files, and the second for output files. It's only a choice.

Also, to echo to screen in a redirected block, just redirect desired screen output to >con

Code: Select all

>"%LOGFILE%" (
   ...
   echo line_1
   echo line_2
   echo line_3
   >CON echo This goes to screen, the others to the stream 
   ...
)

[MicrosoftIsKillingMe]

elzooilogico, those are things that I had not even considered, so your post is helpful to me - on each point - so thank you for the additional explanations.

[taripo]

I suppose those are some reason to do it but when considering readability it's worth considering how convention can make things easier to recognise/read.

I think there are many reasons why putting it afterwards is clearer..

A)The convention most people use is putting it afterwards.. the first time I ever saw it before was this forum..

B)With the arrow of > or <, you get the sense that what is on the side of the bigger part of the arrow is coming in and what is on the pointy side of the arrow is where it's going and it indicates an order 'cos the fat side of the arrow has what's coming in which is the first thing and the pointy side has where it's going. And if the arrow sits between the command and the file and points, then it indicates whether it's input or output in a very readable way.

C)And in English and Maths we tend to think in terms of e.g. for english, subject verb object. or in mathematics, infix operators so- operand operator operand 3+5, rather than +(3,5). There are times when looking at something in prefix can arguably be clearer like /(7,3)=(2,1) i.e (7 / 3 = 2 remainder 1). But some operators are much clearer as infix, like x>5 to indicate that x is greater than 5, is visually a bit clearer than >(x,5) or G(x,5). The fat and pointy side of > and < are useful with indicating input/output too when the symbol is infix.

In the case of echo, then sure you lose a little readability because there's an issue of whitespace mattering. so you do echo asdf>blah. But since echo is so simple, and it's so common to echo something and output to a file, that it's still pretty easy to read.

[aGerman]

The issue with a single digit at the end of a line is still valid. And it's just a matter of habit how you read something. You're complaining because the direction western people read is left to right. True. But would you ever consider SET A=B is meant that A is assigned to B? You're used to read the assignment right to left. That's it. In terms of best practice it's sometimes worth to give up a habit.

Steffen

[MicrosoftIsKillingMe]

Just to illustrate the other option for trailing space elimination with parentheses,

Code: Select all

echo 1  >  bad.txt 
(echo 1)  >  good.txt 

It is already obvious to some of you, but note that the following do not produce the same result

Code: Select all

> one.txt    (echo 1)  
> two.txt    echo  1  

as the second of this pair redirects the extra space before the 1, as well as any trailing spaces after the 1. So parentheses may still be useful or add clarity in this sequence.

If you took

Code: Select all

echo 1 > foo.bar

and "cut" the first 7 bytes including the space after the 1 to form

Code: Select all

> foo.bar echo 1 

then you would still have the trailing space that is redirected.

aGerman, so there's no misunderstanding, I'm neither disagreeing nor complaining with anything you said. These are merely illustrations for clarity.

When testing variations of these examples be alert that, as pointed out earlier by aGerman, the consecutive sequence 1> has a different interpretation.

taripo, my sequential comprehension process is exactly in line with your description - you articulated it well - and accordingly I have no intuitive flow with the other sequence; but I'm going to try to be open to the possibility that my habit might sometimes conflict with best practice.