Hi
ich muss so ein LInux make system nach Windows portieren.
Make unter windows kommt mit den Leerzeichen nicht zu recht.
Gibt es eine einfache Lösung:
GNU_INSTALL_ROOT := C:\Program Files (x86)\GNU Tools Arm Embedded\7
2018-q2-update
Makefile:231: Cannot find include folder: C:\Program
Makefile:231: Cannot find include folder: Files
Makefile:231: Cannot find include folder: (x86)\GNU
Makefile:231: Cannot find include folder: Tools
Makefile:231: Cannot find include folder: Arm
Makefile:231: Cannot find include folder: Embedded\7
Makefile:231: Cannot find include folder:
2018-q2-update/arm-none-eabi/include
....
pegel schrieb:> Anführungszeichen?
Auch schon probiert. Aber wie löse ich das nächste Problem:
GNU_INSTALL_ROOT := "C:\Program Files (x86)\GNU Tools Arm Embedded\7
2018-q2-update"
Cannot find: '"C:\Program Files (x86)\GNU Tools Arm Embedded\7
2018-q2-update"/bin/arm-none-eabi-gcc'.
> Gibt es eine einfache Lösung:
Klar, aender die Verzeichnisnahmen. Alles was ueber den ueblichen
Standard seit den 80ern hinausgeht ist eine Garantie fuer Aerger und hat
auf Entwicklungsrechnern nichts verloren.
Selbst wenn du es heute irgendwie hinbiegen kannst, es kommt immer der
Tag
an dem du es bereuen wirst.
Olaf
Versuch erst mal herauszufinden, welches "make" du da verwendest.
Ist es das, was mit den "GNU Tools ARM Embedded" mitgekommen ist, oder
ist es ein anderes, was sich im %PATH% davorgemogelt hat?
Unter Windof "xxx%20xxx2 das "%20" steht für Lehrzeichen im Dateinamen.
;-)
Aber ansonsten 100% nach:
Olaf schrieb:> Selbst wenn du es heute irgendwie hinbiegen kannst, es kommt immer der> Tag> an dem du es bereuen wirst.Nichtstandard Charakters können Probleme geben, es gibt auch
Backup-Programme die nicht damit zurecht kommen!
73 55
Olaf schrieb:> Klar, aender die Verzeichnisnahmen. Alles was ueber den ueblichen> Standard seit den 80ern hinausgeht ist eine Garantie fuer Aerger und hat> auf Entwicklungsrechnern nichts verloren.
So ein Blödsinn. Das funktioniert seit > 30 Jahren unter Windows, alle
Tools unterstützen Leerzeichen in Pfaden.
Mat. K. schrieb:> Cannot find: '"C:\Program Files (x86)\GNU Tools Arm Embedded\7> 2018-q2-update"/bin/arm-none-eabi-gcc'.
Der gesamte Dateiname muß in Anführungszeichen! Wie kommt man nur auf so
eine Idee die Anführungszeichen mitten in den String zu setzen. Da würde
ich als Makeprogramm auch "Nöööö" sagen.
udok schrieb:> alle> Tools unterstützen
Zumindest neuere, ;-)
Ältere Tools, selbst der IAR hatte bis ein paar Versionen zuvor seine
Probleme damit und konnte die Files dann nicht finden.
NTBACKUP macht übrigens auch gerne Probs mit Lehrzeichen, da kommt es
ein wenig drauf an wo sie stehen.
Am Anfang des Dateinamens, packen die wenigsten Tools.....;-)
Insofern empfiehlt es sich tatsächlich "_"(underline),
anstelle von" "(Space) zu verwenden.
Oliver S. schrieb:> Dann ändere mal "Program Files" unter Windows...
Den Entwickler oder Produkt Manager, der sich diesen Namen mit Space
ausgedacht hat, würde ich gerne mal in den Hintern treten.
Das hat dazu geführt, dass sich einige Programme außerhalb dieses
Verzeichnisses installieren.
Michael
> So ein Blödsinn. Das funktioniert seit > 30 Jahren unter Windows,
Ich hab keinen Zweifel daran das die mittlerweile auf dem Level
von "geht meistens" sind. Wuerde mir nur nicht ausreichen.
Olaf
Michael D. schrieb:> Den Entwickler oder Produkt Manager, der sich diesen Namen mit Space> ausgedacht hat, würde ich gerne mal in den Hintern treten.
Da trittst du die falschen. Windows funktioniert absolut einwandfrei mit
Leerzeichen im Pfad.
Treten musst du diejenigen, die manche Linux-Tools fehlerhaft an Windows
angepasst haben, denn das sind die, die die Probleme machen.
Oliver
Michael D. schrieb:> Den Entwickler oder Produkt Manager, der sich diesen Namen mit Space> ausgedacht hat, würde ich gerne mal in den Hintern treten.>> Das hat dazu geführt, dass sich einige Programme außerhalb dieses> Verzeichnisses installieren.
Das liegt aber daran, daß die entsprechenden Entwickler unfähig waren.
Mat. K. schrieb:> Hi> ich muss so ein LInux make system nach Windows portieren.
GNU Make? Dann schnapp dir die Dokumentation
https://www.gnu.org/software/make/manual/make.html und durchsuche sie
komplett nach "Microsoft", "MS-DOS" und "MS-Windows". Es gibt so die ein
oder andere Anmerkung zu Einschränkungen und Änderungen unter Windows.
Zeno schrieb:> Der gesamte Dateiname muß in Anführungszeichen! Wie kommt man nur auf so> eine Idee die Anführungszeichen mitten in den String zu setzen. Da würde> ich als Makeprogramm auch "Nöööö" sagen.
Ach, Windows kann das. Zumindest je nach Mondphase funktionieren so
Dinge wie
> Das liegt aber daran, daß die entsprechenden Entwickler unfähig waren.
Ja, und es gibt so viele davon und soviele Sachen die diese Entwickler
programmieren und soviele Tools und Libaries.
Und es gibt kluge Menschen die daraus etwas lernen koennen...
Olaf
udok schrieb:> …> So ein Blödsinn. Das funktioniert seit > 30 Jahren unter Windows, alle> Tools unterstützen Leerzeichen in Pfaden.
1. ist das kompletter Unsinn, dass das in der Windowswelt seit 30 Jahren
funktioniert
2. haben haben IMHO white spaces in Dateinamen nichts zu suchen
Michael D. schrieb:> Den Entwickler oder Produkt Manager, der sich diesen Namen mit Space> ausgedacht hat, würde ich gerne mal in den Hintern treten.
Naja könnte man machen, aber letzendlich wurden für so etwas Quotes
erfunden und das funktioniert definitiv, wenn man es nicht so macht wie
der TO und nur einen Teil des vollständigen Dateinamens mit Quotes
versieht.
PS: Dann müßte man auch den in den Hintern treten, der sich ausgedacht
hat ein Datei-/Verzeichnisattribut durch eine führenden Punkt
darzustellen.
Εrnst B. schrieb:> Linux kann auch Backlash \ und TAB \t im Dateinamen.
Ja, damit hat wohl auch adobe nicht gerechnet. Dessen Reader für Linux
erzeugt gerne mal im aktuellen Arbeitsverzeichnis eine Datei namens
"C:\nppdf32Log\debuglog.txt".
Zeno schrieb:> Naja könnte man machen, aber letzendlich wurden für so etwas Quotes> erfunden und das funktioniert definitivZeno schrieb:> Käse, geht immer!
Und Pauschalisierungen sind immer falsch :)
Die GNU-Make-Syntax kennt im Gegensatz zu Shells kein Quoting mit " oder
'. Deswegen tut sich Make mit Spaces in Pfaden ziemlich schwer. Das ist
ein Mangel und für ein Tool aus dem unixoiden Umfeld eigentlich
untypisch. Man kann Leerzeichen zwar mit \ escapen, aber auch das führt
nicht immer zum Erfolg. Da in Unix/Linux sowieso kaum Spaces in Datei-
oder Verzeichnisnamen verwendet werden (und erst recht nicht in
Quellcodebäumen), stört dies praktisch niemanden.
Ein Makefile besteht aber nicht nur aus Make-Syntax, sondern enthält
auch Shell-Syntax, nämlich in den Recipes. Anders als Make kann die
Shell kann mit Spaces und sogar Steuerzeichen in Dateinamen sehr gut
umgehen. Bei einfachen Makefiles kann die Leerzeichenproblematik oft
vollständig an die Shell delegiert und damit gelöst werden. Wenn im
Makefile jedoch mit Listen von Dateien gearbeitet wird, gehen die
Probleme los, weil zur Trennung der Listenelemente ebenfalls Spaces
verwendet werden.
Unter Windows kommt noch erschwerend hinzu, dass die Behandlung von
Spaces, Quotes und Escapes in Kommandozeilen – anders als in Unix/Linux
– nicht zentral (und damit einheitlich) von der Shell vorgenommen wird,
sondern den jeweils aufgerufenen Programmen obliegt, die diesbezüglich
teilweise jeweils ihre eigenen Süppchen kochen.
Deswegen kann ich Olaf nur zustimmen:
Olaf schrieb:> Klar, aender die Verzeichnisnahmen.> ...> Selbst wenn du es heute irgendwie hinbiegen kannst, es kommt immer der> Tag an dem du es bereuen wirst.
Das wird jeder bestätigen, der sich schon etwas intensiver mit Makefiles
beschäftigt hat.
Eine weitere Option wäre, anstelle von Make ein anderes Build-Tool wie
bspw. SCons zu verwenden.
Edit:
Das Problem des TE bezieht sich auf den Pfad der Toolchain. Falls dieser
Pfad der einzige mit Spaces ist und nur in Recipes verwendet wird,
sollte es eine Lösung auch ohne Umbenennung der Verzeichnisse geben. Ich
habe leider kein Windows mit installiertem Make hier, deswegen kann ich
diesbezüglich nichts ausprobieren.
Oliver S. schrieb:> Treten musst du diejenigen, die manche Linux-Tools fehlerhaft an Windows> angepasst haben, denn das sind die, die die Probleme machen.
So isses. Wenn man sich auf die Fahnen schreibt, portabel sein zu
wollen, dann sollte man es auch tatsächlich sein. Sonst macht man sich
(zuindest bei einer derartigen Trivialität) doch eher lächerlich.
Betrifft übrigens natürlich nicht nur Leerzeichen in Pfaden, sondern
generell die Behandlung von Pfaden unter den verschiedenen OS.
c-hater schrieb:>> Treten musst du diejenigen, die manche Linux-Tools fehlerhaft an Windows>> angepasst haben, denn das sind die, die die Probleme machen.>> So isses. Wenn man sich auf die Fahnen schreibt, portabel sein zu> wollen, dann sollte man es auch tatsächlich sein.
Portabel ist es ja. Das Problem ist nicht das Betriebssystem selbst,
sondern die Leerzeichen im Pfadnamen, unabhängig vom Betriebssystem.
> Betrifft übrigens natürlich nicht nur Leerzeichen in Pfaden, sondern> generell die Behandlung von Pfaden unter den verschiedenen OS.
Diese merkwürdige Geschichte mit den Laufwerksbuchstaben (wo A und B
immer noch für Disketten reserviert sind) hätten sie in den vielen
Jahrzehnten nun wirklich langsam mal abschaffen können. Unter DOS war
das ja vielleicht noch zeitgemäß, aber heute?
Rolf M. schrieb:> Diese merkwürdige Geschichte mit den Laufwerksbuchstaben (wo A und B> immer noch für Disketten reserviert sind) hätten sie in den vielen> Jahrzehnten nun wirklich langsam mal abschaffen können. Unter DOS war> das ja vielleicht noch zeitgemäß, aber heute?
Die Sache ist nicht merkwürdig, sondern auf einem Single-User System
recht logisch und einfach zu merken.
MS darf dir sicher die Danke-Emails zum Beantworten weiterleiten, wenn
>100 Millionen ihre Dokumente nicht mehr finden?
RolfM.schriebimBeitrag#7138013:
>Portabelistesja.DasProblemistnichtdasBetriebssystemselbst,>sonderndieLeerzeichenimPfadnamen,unabhängigvomBetriebssystem.
oder besser doch:
Rolf M. schrieb:> Portabel ist es ja. Das Problem ist nicht das Betriebssystem selbst,> sondern die Leerzeichen im Pfadnamen, unabhängig vom Betriebssystem.
Yalu X. schrieb:> Das wird jeder bestätigen, der sich schon etwas intensiver mit Makefiles> beschäftigt hat.
Meine größeren Projekte für die Firma habe ich mit Make unter Windows
gemacht und das funktionioert bestens. Allerdings habe ich nicht GNU
make genommen sondern das von Borland.
Wenn es denn unbedingt GNU make sein soll und das zu doof ist mit
Leerzeichen umzugehen, dann packt man das halt in eine BAT- oder
CMD-Datei und ruft das über diesen Umweg auf. Damit delegiert man das
Ganze quasi an die "Shell" und die kann das unter Windows.
Yalu X. schrieb:> Unter Windows kommt noch erschwerend hinzu, dass die Behandlung von> Spaces, Quotes und Escapes in Kommandozeilen – anders als in Unix/Linux> – nicht zentral (und damit einheitlich) von der Shell vorgenommen wird,> sondern den jeweils aufgerufenen Programmen obliegt, die diesbezüglich> teilweise jeweils ihre eigenen Süppchen kochen.
Behauptet einer der vorwiegend mit unixoiden Systemen arbeitet. Ich
kenne kein Windowsprogramm welche nicht mit Leerzeichen umgehen kann,
sie müssen aber eben in Quotes und zwar das gesamter Konstrukt - nicht
so wie es der TO gemacht hat.
Yalu X. schrieb:> Deswegen kann ich Olaf nur zustimmen:>> Olaf schrieb:>> Klar, aender die Verzeichnisnahmen.>> ...
Das komm eben auch von jemanden der vorzugweise mit unixoiden Systemen
arbeitet."C:\Program Files (x86)" kann man nicht so einfach umbenennen,
da dies ein systemrelevantes Verzeichnis ist. Alle Programme die den
Windowstandard einhalten vertrauen darauf das dieses Verzeichnis
existiert. Im Übrigen ist in dem Dateinamen des TO ein Leerzeichen
zuviel und zwar das zwischen Files und (x86). Bedeutet selbst wenn er es
quotet wird es nicht funktionieren.
Das Verzeichnis wird bei der Installation von Windows automatisch
angelegt und man kann es meines Wissen auch nicht bei der Installation
ändern. WEnn man es ändern will dann geht das nur mit größeren
Eingriffen ins System und die Registry, wobei die Chancen das danach
nichts mehr funktioniert gar nicht so schlecht stehen.
Man kann das Problem nur dadurch umgehen indem man seine Programme eben
nicht in dieses Verzeichnis installiert. Das funktioniert zwar ist aber
nicht mehr windowskonform.
Rolf M. schrieb:> Das Problem ist nicht das Betriebssystem selbst,> sondern die Leerzeichen im Pfadnamen, unabhängig vom Betriebssystem.
Leerzeichen in Pfad- oder Dateinamen sind kein Problem, aber autistische
Programmierer sind eines, die ihre eigene Unfähigkeit damit kaschieren,
indem sie behaupten, daß das falsch wäre.
Sogar macOS (ein echtes Desktop-Unix) kommt mit Leerzeichen in Pfaden
zurecht, da sollten es doch ein paar autistische Linux-Hanseln nach bald
30 Jahren Linux auch mal auf die Reihe bekommen.
Die pragmatische Lösung ist wie üblich einfach.
Man erzeugt parallel zum "Verzeichnisnamen mit Leerzeichen"
einen Link eben ohne Leerzeichen. Wen das im Rootlaufwerk
stört, kann diesen Link auch auf einem NTFS-Laufwerk erzeugen.
Vorgemacht hat es M$ sogar selbst, allerdings andersherum:
Da ist "Documents and Settings" nur noch ein Link auf "Users".
Genauso kann man einen Link "Winapps" erzeugen, der ein
Synonym für "Program Files" ist.
Für Altsystem emphiehlt sich "Junction". Ansonsten gibt
es wohl aus ein "mklink" unter neueren Systemen.
udok schrieb:> Rolf M. schrieb:>> Diese merkwürdige Geschichte mit den Laufwerksbuchstaben (wo A und B>> immer noch für Disketten reserviert sind) hätten sie in den vielen>> Jahrzehnten nun wirklich langsam mal abschaffen können. Unter DOS war>> das ja vielleicht noch zeitgemäß, aber heute?>> Die Sache ist nicht merkwürdig, sondern auf einem Single-User System> recht logisch und einfach zu merken.
Ja, wie gesagt: Bei DOS mag das noch gepasst haben. Bei Windows NT
hätten sie es dann mal langsam abschaffen können.
> MS darf dir sicher die Danke-Emails zum Beantworten weiterleiten, wenn>>100 Millionen ihre Dokumente nicht mehr finden?
Naja, sie tun ja ziemlich viel, um diese Altlast vor dem Benutzer
weitgehend zu verstecken.
Rolf M. schrieb:> Ja, wie gesagt: Bei DOS mag das noch gepasst haben. Bei Windows NT> hätten sie es dann mal langsam abschaffen können.
Ist abgeschafft - irgendwie, und in typischer Microsoft-Art hässlich,
unhandlich und halb kaputt. So dass man einen ziemlichen Sockenschuss
haben muss das standardmäßig zu benutzen.
Lass dir den Volumennamen (Volume-GUID ) deines C: Laufwerkes anzeigen
1
mountvol c: /L
2
\\?\Volume{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\
So, und jetzt ist der Mechanismus auch schon kaputt. Man kann den
Volumennamen nämlich nicht zum Anzeigen der Wurzel des Volumes (hier
C:\) verwenden. Man muss mindestens ein Verzeichnis angeben (GUID durch
eigene ersetzen).
1
rem Funktioniert als Ersatz für C:\ nicht
2
dir \\?\Volume{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\
3
Falscher Parameter.
4
5
rem Funktioniert (C:\Users)
6
dir \\?\Volume{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\Users
Im Explorer geht beides nicht. Wo kämen wir dahin wenn Microsofts eigene
Programme die eigene Syntax verstehen würden.
Was man noch machen kann ist Laufwerksbuchstaben bis auf C: los zu
werden. Mit dem Risiko dass sich irgend was in Windows selber bekotzt.
Angenommen du hast ein Laufwerk D: mit irgendwelchen Daten:
1
mountvol d: /L
2
\\?\Volume{789ddf93-8c56-11db-9ebe-806d6172696f}
Dann kannst du das Laufwerk auch unter C: aufhängen. Als Admin:
Mögliche Werte für VolumeName mit aktuellen Bereitstellungspunkten:
7
...
8
\\?\Volume{789ddf93-8c56-11db-9ebe-806d6172696f}\
9
D:\
10
C:\datadrive\
11
...
12
13
dir c:\datadrive
Den Bereitstellungspunkten D:\ könnte man jetzt noch löschen.
Das ist halbwegs brauchbar, weil man auch das Wurzelverzeichnis eines
Volumes mounten kann. Aber eben nur unter irgend einem Pfad mit einem
Laufwerksbuchstaben.
> Naja, sie tun ja ziemlich viel, um diese Altlast vor dem Benutzer> weitgehend zu verstecken.
Was sie tun ist eher halbherzig und nicht wirklich zu Ende gedacht.
Viel bedenklicher ist, dass die Linuxhackerz jetzt, oder sogar
schon vor einer Weile mit diese GUID-Dreck angefangen haben.
Ein händisch vergebenes Label hat wieder irgendwelchen Idioten
nicht gereicht.
Hannes J. schrieb:> Ist abgeschafft - irgendwie, und in typischer Microsoft-Art hässlich,> unhandlich und halb kaputt. So dass man einen ziemlichen Sockenschuss> haben muss das standardmäßig zu benutzen.>> Lass dir den Volumennamen (Volume-GUID ) deines C: Laufwerkes> anzeigenmountvol c: /L> \\?\Volume{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\>> So, und jetzt ist der Mechanismus auch schon kaputt. Man kann den> Volumennamen nämlich nicht zum Anzeigen der Wurzel des Volumes (hier> C:\) verwenden. Man muss mindestens ein Verzeichnis angeben (GUID durch> eigene ersetzen).> rem Funktioniert als Ersatz für C:\ nicht> dir \\?\Volume{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\> Falscher Parameter.> rem Funktioniert (C:\Users)> dir \\?\Volume{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\Users>> Im Explorer geht beides nicht. Wo kämen wir dahin wenn Microsofts eigene> Programme die eigene Syntax verstehen würden.
Es ist immer wieder traurig, wenn Leute mit Linux Hintergrund die Welt
erklären wollen.
Du hast deine kleine Linuxwelt mit der Muttermilch aufgesaugt, und alle
anderen Lösungen sind erst mal Bähhh - mag ich nicht - kann nicht sein -
was bilden die sich ein - wer sind die überhaupt - keiner darf gegen die
reine Linux Lehre erstossen - her mit dem Scheiterhaufen.
Und erzähle mir blos nicht, das Linux intuitiv ist. Das was du als
richtig
wahrnimmst ist einfach jahrelange Gewohnheit, böse Zungen sagen auch
Stockholmsyndrom.
Das sind keine Windows Pfade, sondern NT Pfade. Mit dem Prefix "\\\\?\"
greifst du
auf den Windows Namespace zu. Das ist nicht für den Anwender gedacht.
Unter NT gibt es einen "Object Manager", der alle möglichen Pfade und
Devices verwaltet.
Darin gibt es mehrere Namespaces für die internen Subsystem wie Win32
und OS2.
Im Device Manager gibt es Verküpfungen zu den intern verwendeten
Geräten,
etwa die DOS Devices PRN, LPT, CON, NULL, und auch die
Laufwerkbuchstaben.
Das die Volumes mit GUIDs angesprochen werden ist nicht ganz verkehrt,
wenn wenn man
etwa an Wechsellaufwerke denkt, oder an Links zwischen Laufwerke.
Der Mount Punkt oder der Bezeichner C: kann sich ändern, wie du schon
bemerkt hast,
und auch im Netzwerk sollen die Links ihre Gültigkeit behalten.
Der Benutzer hat zum Glück mit diesen Langen Nummern nichts zu tun,
genauso wie der im
Normalfall auch keine IP6 Addressen auswendig lernen muss.
Der richtige Weg unter Windows, wie man Volumes in einem Verzeichnis
mounted
ist die Dateiträgerverwaltung, da klickst du auf ein Laufwerk und kannst
eine Aufhängepunkt angeben oder den Lauferkbuchstaben ändern. Aber wer
braucht sowas?
Gruss,
Udo
wombles schrieb:> Viel bedenklicher ist, dass die Linuxhackerz jetzt, oder sogar> schon vor einer Weile mit diese GUID-Dreck angefangen haben.>> Ein händisch vergebenes Label hat wieder irgendwelchen Idioten> nicht gereicht.
Natürlich waren das keine Idioten. Jeder der etwas weiterdenkt, erkennt
das ein händisch vergebenes Label von jemandem händisch vergeben werden
muss.
Dazu braucht es einen Sysadmin, der bezahlt werden will. Das Linuxhacker
das in ihrer Freizeit machen ist deren Ding, aber unter Windows wollen
die Leute
einfach ihre Arbeit machen.
Zeno schrieb:> Meine größeren Projekte für die Firma habe ich mit Make unter Windows> gemacht und das funktionioert bestens. Allerdings habe ich nicht GNU> make genommen sondern das von Borland.
Borland-Make ist – was die Leerzeichen in Dateinamen betrifft – auch
nicht besser als GNU-Make. Nehmen wir einfach mal das folgende Beispiel
aus dem Handbuch:
1
mylib.lib: f1.cpp f2.cpp
2
bcc -c $?
3
&tlib mylib -+$(?:.cpp=.obj)
Jetzt nennen wir "f2.cpp" in "f 2.cpp" um und setzen den neuen Namen im
Makefile wie von dir vorgeschlagen in Anführungszeichen:
1
mylib.lib: f1.cpp "f 2.cpp"
2
bcc -c $?
3
&tlib mylib -+$(?:.cpp=.obj)
Ist nun "f 2.cpp" neuer als mylib.lib, generiert make die folgenden
beiden Kommandos:
1
bcc -c f 2.cpp
2
tlib mylib -+f 2.obj
Beim Aufruf von bcc und tlib werden die Anführungszeichen unterschlagen,
so dass "f" und "2.cpp" als zwei separate Argumente interpretiert
werden.
> Wenn es denn unbedingt GNU make sein soll und das zu doof ist mit> Leerzeichen umzugehen, dann packt man das halt in eine BAT- oder> CMD-Datei und ruft das über diesen Umweg auf.
Wie würdest du das konkret im obigen Beispiel machen?
wombles schrieb:> Vorgemacht hat es M$ sogar selbst, allerdings andersherum:> Da ist "Documents and Settings" nur noch ein Link auf "Users".
Nein. Du hast mal definitiv kein Ahnung. Aber sowas von...
Zeno schrieb:> Wie kommt man nur auf so eine Idee die Anführungszeichen mitten in den> String zu setzen.
Je nach Anwendung kann das nötig sein. Benötigt man innerhalb eines
Strings ein Anführungszeichen, nimmt man stattdessen das Hochkomma oder
doppelt das Anführungszeichen. Funktioniert z.B. in VB/VBA gut.
c-hater schrieb:> wombles schrieb:>>> Vorgemacht hat es M$ sogar selbst, allerdings andersherum:>> Da ist "Documents and Settings" nur noch ein Link auf "Users".>> Nein. Du hast mal definitiv kein Ahnung. Aber sowas von...
Jaja. Du weisst was Jaja heisst.
1
C:\>junction "Documents and Settings"
2
3
Junction v1.03 - Win2K junction creator and reparse point viewer
Udo K. schrieb:> MS nmake kann damit umgehen.
Ja, da funktioniert es tatsächlich. Ich verstehe ehrlich gesagt nicht
ganz, warum die anderen Makes (GNU und Borland) die Anführungszeichen
(bei Borland) bzw. die Backslash-Escapes (bei GNU), die ja syntaktisch
vorgesehen sind und in den Prerequisites und Targets auch richtig
interpretiert werden, nicht einfach an die Shell-Kommandos in den
Recipes durchreichen.
Weil es nicht geht, braucht es keiner... und weil es keiner braucht geht
es nicht... schade eigentlich.
Es wird da auch nicht mehr viel weiterentwickelt, weil make zu
altmodisch ist.
Fast alle IDEs sind von make weg.
Und neben den Leerzeichen gibt es etliche andere Probleme, sobald der
Build Prozess etwas komplizierter wird.
Udo K. schrieb:> Fast alle IDEs sind von make weg.
Aber nur die für Sprachen mit eigenem build-System, die schon immer ohne
make auskamen.
Der Rest wird es bis ans Ende aller Zeiten weiterverwenden.
Oliver
Walter K. schrieb:> 2. haben haben IMHO white spaces in Dateinamen nichts zu suchen
Sage das Microsoft. Windows 10 legt ja sogar das Home Verzeichnis mit
Leerzeichen an. Viel Glück bei dem Versuch, es nachträglich
umzubenennen. Es geht "theoretisch".
Oliver S. schrieb:>> Fast alle IDEs sind von make weg.>> Aber nur die für Sprachen mit eigenem build-System, die schon immer ohne> make auskamen.>> Der Rest wird es bis ans Ende aller Zeiten weiterverwenden.
Ich kann mich gar nicht mehr erinnern, wann ich das letzte Mal Software
compiliert habe, die noch Make verwendet.
Bei den älteren Sachen gibt es das verstaubte autoconf, das auf Make
aufbaut, heutzutage sehe ich oft CMake, Ninja oder MSBuild. In Eclipse
sehe ich auch kein Make, keine Ahnung was die intern verwenden.
hatte mal ein ähnliches Problem mit Verzeichnispfaden, die die
path-Anweisung nich gefunden hat.
Lösung war, im make-Verzeichnis eine Datei anzulegen, die per Batch das
Verzeichnis aufgerufen hat:
makefile:
...
MCU = atmega328p
#MCU = atmega2560
#MCU = atmega1284p
#MCU = atmega644
#MCU = atmega8
#MCU = atmega32
# Target file name (without extension).
TARGET = main
include mk_target.txt
...
mk_target.txt:
SRC = $(TARGET).c _i2clcd.c _i2cmaster.c _std_lib_lcd.c
Hilfsdatei _i2clcd.c:
# include <c:\ra_ide\src\i2clcd.c ></ File >
Vielleicht geht so was Ähnliches
die Batch-Datei müsste unter Windows Leerzeichen können.
Zeno schrieb:> Mat. K. schrieb:>> Cannot find: '"C:\Program Files (x86)\GNU Tools Arm Embedded\7>> 2018-q2-update"/bin/arm-none-eabi-gcc'.>> Der gesamte Dateiname muß in Anführungszeichen! Wie kommt man nur auf so> eine Idee die Anführungszeichen mitten in den String zu setzen. Da würde> ich als Makeprogramm auch "Nöööö" sagen.
Ist doch eindeutig dass es nicht an dem Leerzeichen liegt (da korrekt
gequotet) sondern an den fehlenden Backslashs. Irgendwo setzt da ein
Parser das nicht richtig um.
Im übrigen werden die Pfade generiert (über Variablen die oft
absichtlich nicht gequotet werden, damit sie auch ungesetzt
funktionieren)
Alexander schrieb:> Ist doch eindeutig dass es nicht an dem Leerzeichen liegt (da korrekt> gequotet)
Gerade im Zusammenhang mit make hatte ich in der Vergangenheit auch
schon Probleme trotz korrekt gequoteter Leerzeichen. Windows unterstützt
/ und \ in Pfaden, auch gemischt.
Michael D. schrieb:>> Dann ändere mal "Program Files" unter Windows...> Den Entwickler oder Produkt Manager, der sich diesen Namen mit Space> ausgedacht hat, würde ich gerne mal in den Hintern treten.
Das hat Microsoft mit Windows 95 absichtlich gemacht, um
Anwendungsentwicklern klarzumachen, dass Leerzeichen jetzt existieren
und auch behandelt werden müssen. Es hat auch funktioniert: Nach kurzer
Zeit kamen die meisten Programme damit klar.
Außer in Sprachen, wo die Lokalisierungsexperten das kaputtgemacht
haben, zum Beispiel "deutsch". Da hat der Umstieg dann noch 15 Jahre
länger gedauert.
Ob das klug war oder nicht sei mal dahingestellt.
> Das hat dazu geführt, dass sich einige Programme außerhalb dieses> Verzeichnisses installieren.
Das sollte einem eigentlich zu denken geben, was diese "einige
Programme" betrifft. Nach einem Jahrzehnt oder so.
S. R. schrieb:> Das hat Microsoft mit Windows 95 absichtlich gemacht, um> Anwendungsentwicklern klarzumachen, dass Leerzeichen jetzt existieren> und auch behandelt werden müssen. Es hat auch funktioniert: Nach kurzer> Zeit kamen die meisten Programme damit klar.
Das der Ordner im Explorer aber als "Programme" angezeigt wird, das kann
man Menschen mit normal funktionierendem Verstand nicht erklären.
Ebenso dass der Explorer immer noch Dateiendungen ausblendet, während
man Leuten sicherheitshalber dazu rät, auf die Endung zu schauen bevor
man etwas öffnet.
Da bauen sie lieber 1000 Security Workarounds, anstatt diese simple
Schnapsidee zu entfernen oder zumindest standardmäßig zu deaktivieren.
Sie ist ja deaktivierbar.
> Ob das klug war oder nicht sei mal dahingestellt.
Gar nicht drüber nachdenken, man regt sich sonst nur auf (so wie ich
gerade).
Stefan F. schrieb:> Das der Ordner im Explorer aber als "Programme" angezeigt wird, das kann> man Menschen mit normal funktionierendem Verstand nicht erklären.
Der Ordner hieß "Program Files". Das deutsche Lokalisierungsteam hat
daraus dann "Programme" und damit den Zweck kaputt gemacht. Betrifft
auch andere Sprachen.
> Ebenso dass der Explorer immer noch Dateiendungen ausblendet, während> man Leuten sicherheitshalber dazu rät, auf die Endung zu schauen bevor> man etwas öffnet.
Das "auf die Endung schauen" wird inzwischen wegautomatisiert. Vor ein
paar Tagen habe ich eine E-Mail von GMail zurückbekommen, weil darin
eine ZIP-Datei war, in der sich zwei COM-Dateien für CP/M befanden. Das
ist gar zu gefährlich, darf man nicht.
> Da bauen sie lieber 1000 Security Workarounds, anstatt diese simple> Schnapsidee zu entfernen oder zumindest standardmäßig zu deaktivieren.
Du denkst falsch. Schau in die Welt der mobilen Endgeräte und du siehst,
wo die Reise hingeht. Das Ziel ist, vom Konzept der "Datei" (als
unstrukturiertem Bytehaufen) wegzukommen und durch "Dokumente" (gegebene
Struktur und Metadaten) zu ersetzen.
>> Ob das klug war oder nicht sei mal dahingestellt.> Gar nicht drüber nachdenken, man regt sich> sonst nur auf (so wie ich gerade).
Aufregen bringt nichts. Du musst aber auch bedenken, dass der
Computermarkt um DOS/Windows 3.1 herum deutlich kleiner war, die
Nutzerzahlen kleiner und die Nutzer in der Regel nicht komplett hilflos.
Das hat sich ab Windows 95 massiv geändert.
Inzwischen ist man de facto zur Nutzung von Computern gezwungen. Also
auch diejenigen, die dafür einfach zu doof sind. Und für die muss man
alles, was technisch aussieht, verstecken - sonst gibt's Mecker auf
Social Media und viel zu teure Callcenter, die tagein-tagaus den
gleichen Scheiß erklären müssen.
Die Menschheit als Ganzes ist doof. Schau dich um (oder in die
Nachrichten), dann siehst du es doch selbst. Denken kostet Energie und
Energie ist grad selten und teuer.
Große Nutzerzahlen erzwingen standardisierte Systeme und damit auch den
kleinsten gemeinsamen Nenner über alles. Wenn man nicht mehr
voraussetzen kann, dass der Kunde lesen kann (und wenn es die
Dreijährige am Kinder-Youtube-Tablet ist), dann setzt man das eben nicht
mehr voraus.