meaning of * in fileappend

[marypoppins_1]

hello.

Code: Select all

FileAppend, %key%, *%x1%

what exactly does the * mean in the path of the fileappend function? how would it behave if removed?

thanks in advance

[mikeyww]

End of line (EOL) translation: To disable EOL translation, prepend an asterisk to the filename. This causes each linefeed character (`n) to be written as a single linefeed (LF) rather than the Windows standard of CR+LF. For example: *C:\My Unix File.txt.
Source: FileAppend - Syntax & Usage | AutoHotkey v1

[marypoppins_1]

yeah i know but i didn't understand it very much. does it mean the new line (enter key) will show as an enter instead of cr_lf?

[mikeyww]

Enter, line break, carriage return, and line feed

Enter is a keyboard key but not a text character. Windows typically uses two characters to represent a line break generated by pressing Enter: CR and LF, in sequence. This is a carriage return followed by a line feed. A device called a typewriter physically does this, and so this is what the terms originally meant. The typewriter's cylindrical carriage is returned to the other side, and a line feed is also generated as the carriage is rolled upward slightly. My recollection is that it actually happened in the reverse order, simply because the lever to return the carriage would feed the line as soon as you pressed it. In concept, however, one should return the carriage and then feed the line. For anyone who has used a real typewriter, this concept of CR+LF is perhaps straightforward to understand!

Well, enough about old typewriters. Appending text to a file involves no keys or levers! On your behalf and for your convenience and usability, AHK will normally add CR to sole LF that do not originally have the preceding CR. You can avoid this with the asterisk file prefix.

Many text editors will optionally show these normally invisible white-space characters. Notepad only provides a status-bar indicator of whether the file is "Windows" (with CR and LF) or "Unix", which omits the CR in its text files.

You can see the results simply by running a script and viewing the output.

Code: Select all

#Requires AutoHotkey v1.1.33.11
FileAppend abc`ndef  ,  test1.txt
FileAppend abc`ndef  , *test2.txt
FileAppend abc`r`ndef,  test3.txt
FileAppend abc`r`ndef, *test4.txt
Run test1.txt ; AHK adds CR to sole LF                         => "Windows"
Run test2.txt ; No changes                                     => "Unix" (has only LF)
Run test3.txt ; AHK adds CR to sole LF => No changes           => "Windows"
Run test4.txt ; No changes => the CR is already provided above => "Windows"

[RussF]

Edit: So, as is often the case, @mikeyww and I had the same thoughts - he's just a faster typist! Between the two of them, hopefully your question is answered. My original post is below, before I saw that he had beat me to the punch.



So - a little bit of history is in order here.

CR (Carriage Return) and LF (Line Feed) are holdovers from the days before video terminals, when Teleprinters (also known as Teletypes, like "Kleenex" is used generically for tissues) were the way that humans interfaced with computers. (Yes, I remember those days!) A teleprinter was basically a typewriter with a continuous roll of paper attached. You may have seen them in old movies where news flashes were coming over the "wire".

When the printer portion was active by receiving input either from the human via the keyboard or from the computer via an RS-232 cable, each character received would be printed on the roll of paper and the print head ("carriage" - a holdover from the manual typewriter) would physically advance forward ready to print the next character. In order for the print head to "return" to the left margin, a "carriage return" (CR, ASCII 13) would be sent from the computer or by pressing the "Return" key on the keyboard. This would physically move (return) the print head to the left margin, BUT, it would NOT advance the paper one line - those were separate operations. If you tried to print multiple lines of text with nothing but CRs at the end, they would all print over top of one another.

Now meet the LF (Line Feed - ASCII 10) character. Any time the teleprinter received one of those, the paper would advance, but the print head would not move. Printing "TLFeLFsLFt" would look like this on the paper:

Code: Select all

T
  e
    s
      t

Usually, the manual keyboard was set up in such a way that pressing "Return" would send both a CR and a LF code to the printer, although either could also be sent individually.

Fast forward a little to the advent of the personal computer. Microsoft decided to maintain the standard of sending both a CR and a LF at the end of a line of text within a text file. When Unix (and Linux) were created, it was decided that all that was needed in a text file was the LF character between lines and called it the "New Line"

Things get a little muddy now with software languages that have to accommodate these different methods. AHK has the escaped characters `r ("Return") and `n ("New Line") How do they work? The following screen shots are from Notepad++ with "display all characters" turned on.

If we write the following code with just `r ("Return") between each word:

Code: Select all

FileAppend, This`ris`ra`rtest`r, test.txt

We get the following whether we precede the file name with an asterisk or not:

image.png (3.02 KiB) Viewed 180 times

If we use the following code with just the `n ("New Line") between words and no asterisk:

Code: Select all

FileAppend, This`nis`na`ntest`n, test.txt

We get the Microsoft standard (both CR and LF:

image.png (2.83 KiB) Viewed 180 times

If, however, we preface the file name with an asterisk, i.e.

Code: Select all

FileAppend, This`nis`na`ntest`n, *test.txt

We get the Unix/Linux standard format of just the LF ("New Line") character between words:

image.png (2.59 KiB) Viewed 180 times

All of this really only applies to writing text files with FileAppend. When using any AHK command that searches and/or replaces characters, the `r always only represents the "Carriage Return" character and the `n always represents the "Line Feed" character. This is why you must sometimes search or split a string using both in succession. Note that it is customary to place the CR (`r) before the LF (`n) when searching for the pair.

So, have I totally confused you now? Hope this sheds some light on the subject.

Russ

[mikeyww]

And if you do need a dot-matrix printer, there are probably a few extras in Russ's garage!

That was a great explanation.

[RussF]

And possibly a daisy-wheel printer or two as well, along with my Apple II+ and my Apple III.

Russ

[marypoppins_1]

thank you both of you. have a great day.

[garry]

once I also needed the EOF ascii=26 , EndOfLine . Or to get a new paper-page , sent FF ascii=12 (FormFeed) to old printer .
( long time ago I wanted transfer via seriell connection a file , this only worked when the file had EOF )

Code: Select all

eof:=Chr(26)
F1:= A_ScriptDir . "\test_00.txt"
var:="
(Ltrim join`r`n
Line_1
Line_2  星期二 三月
Line_3
"
)
e:=var . "`r`n" . eof
FileOpen(F1, "w", "UTF-8").Write(e)
try,run,%f1%
return

[RussF]

I was curious about something.

Since writing text to a file using only `n ("New Line") between lines and without a preceding asterisk in the file name writes out a file with both CR and LF between lines, I wondered if I specifically sent both characters when writing a file - would it double up on the CR character?

Code: Select all

FileAppend, This`r`nis`r`na`r`ntest`r`n, test.txt

As it turns out - no, it doesn't. In fact, it doesn't matter whether you precede the file name with asterisk or not, you will always get:

image.png (3.03 KiB) Viewed 156 times

Good design from the creators of AHK.

Russ

[mikeyww]

That is what "No changes" indicates for test3.txt in my script.