Hmm... przez chwilę dam jednak wiarę... i założę że było to UTF-8... pytanie czy z BOM, czy bez.

tuxcnc pisze:Linuxcnc toleruje unikody

Unicode to zbyt ogólne pojęcie... jest ich w sumie kilkanaście... nawet wspomniany powyżej UTF-8 jest w zasadzie w dwóch odmianach... w jakiś 99% przypadków wszyscy stosują "bez BOM"... Pytanie jak się zachowa system gdy nakarmimy go "z BOM", albo jakąś inną odmianą np. UTF-16LE?

tuxcnc pisze: ↑

13 lip 2021, 06:16

Nie.
Czyta nawet jak w jednej linii jest LF a w drugiej CRLF.
Zastanawia mnie tylko po co wypisywać domysły, kiedy sprawdzenie trwa minutę...

Różnie z tym bywa... akurat swój "domysł" oparłem na przygodzie z Sinumerikiem.
Linuxa używam jako zwykłego systemu desktopowego, nie mam na nim żadnego CNC, więc sprawdzenie nie było możliwe.

Co do drugiego napisanego przez Ciebie posta... cóż... nawet mi to na myśl nie przyszło... chyba każdy wie (a przynajmniej powinien), że pliki ODT, czy DOCX to w zasadzie wiele plików umieszczonych w zhierarchizowanych katalogach, na koniec potraktowanych ZIPem... zresztą nagłówek PK na jednym z zaprezentowanych przez Ciebie screenów mówi o tym najdobitniej.

Aha... taka informacja dla założyciela tematu... nikt nie broni pisać we "wrajcie" czy innym procesorze tekstu... po prostu należy wybrać opcję "Zapiszjako", lub "Eksportuj", oraz wskazać, że jako "tekst", "zwykły tekst", czy tym podobne... w każdym razie z rozszerzeniem ".TXT"

Znacznik końca linii... Linux stosuje bodajże CR (ewentualnie LF), w każdym razie pojedynczy, a w Windows jest kombinacja CR LF.
Może co prawda być jeszcze problem ze stroną kodową (ANSI, ISO, UTF) ale raczej byłby inny komunikat... prawdopodobnie nie odczytał by pliku w ogóle.
Najlepiej użyć np. Notepad++ (w Windows) lub czegoś podobnego (VIM w Linuxie też potrafi) co potrafi wyświetlić znaki niedrukowane i informacje o stronie kodowej... Musisz sobie potem utworzyć profil w edytorze, żeby już odpowiednio zapisywał

X102?! a G0 czy G1, a może G2 lub G3?