Forum: Compiler & IDEs Wie: makefile und Leerzeichen im Verzeichnisnamen


von Mat. K. (matthias_kornfield)


Lesenswert?

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
....

von pegel (Gast)


Lesenswert?

Anführungszeichen?

von Mat. K. (matthias_kornfield)


Lesenswert?

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'.

von udok (Gast)


Lesenswert?

Keine Ahnung was du da tust. Hier funktioniert alles wie es soll.
Lies doch mal das Handbuch, anstatt hier Zeit zu verplempern.
1
GNU_INSTALL_ROOT = C:\Program Files (x86)\GNU Tools Arm Embedded\7 2018-q2-update
2
3
default:
4
         echo "[$(GNU_INSTALL_ROOT)]"

von Olaf (Gast)


Lesenswert?

> 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

von Εrnst B. (ernst)


Lesenswert?

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?

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

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

von udok (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

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.

: Bearbeitet durch User
von Josef (Gast)


Lesenswert?

var := xyz
und
var = xyz

werden unterschiedlich behandelt. Immediate und deferred.

von Oliver S. (oliverso)


Lesenswert?

Olaf schrieb:
> Klar, aender die Verzeichnisnahmen.

Dann ändere mal "Program Files" unter Windows...

Oliver

von Michael D. (nospam2000)


Lesenswert?

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

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

> 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

von Oliver S. (oliverso)


Lesenswert?

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

von DerEgon (Gast)


Lesenswert?

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.

von Martin H. (horo)



Lesenswert?

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.

von Kann man, muss man aber nicht (Gast)


Lesenswert?

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
1
dir "C:\Program Files"\"Windows"" "Defender
statt einfach
1
dir "C:\Program Files\Windows Defender"

von Olaf (Gast)


Lesenswert?

> 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

von Walter K. (walter_k488)


Lesenswert?

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

von udok (Gast)


Lesenswert?

WalterK.schriebimBeitrag#7132188:
>>SoeinBlödsinn.Dasfunktioniertseit>30JahrenunterWindows,alle
>>ToolsunterstützenLeerzeicheninPfaden.
>
>1.istdaskompletterUnsinn,dassdasinderWindowsweltseit30Jahren
>funktioniert
>
>2.habenhabenIMHOwhitespacesinDateinamennichtszusuchen

GruesseUdo

von Oliver S. (oliverso)


Lesenswert?

Walter K. schrieb:
> IMHO

Macht ja nix, stört auch keinen. Linux konnte es schon immer, und 
Windows auch schon sehr lange.

Oliver

von Michael M. (Firma: Autotronic) (michael_metzer)


Angehängte Dateien:

Lesenswert?


von Εrnst B. (ernst)


Angehängte Dateien:

Lesenswert?

Linux kann auch Backlash \ und TAB \t im Dateinamen.

Das macht ein
1
#include "inc\test.h"
interessant, wenn es sowohl einen Ordner "inc" mit einer test.h" gibt, 
als auch eine 'inc<TAB>est.h" und eine 'inc<BACKSLASH>test.h" im selben 
Ordner.

von Zeno (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

Olaf schrieb:
> ... auf dem Level
> von "geht meistens" sind.
Käse, geht immer!

von Zeno (Gast)


Lesenswert?

DerEgon schrieb:
> Das liegt aber daran, daß die entsprechenden Entwickler unfähig waren.
So unfähig wie der TO die Quotes richtig zu setzen.

von Rolf M. (rmagnus)


Lesenswert?

Ε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".

von Yalu X. (yalu) (Moderator)


Lesenswert?

Zeno schrieb:
> Naja könnte man machen, aber letzendlich wurden für so etwas Quotes
> erfunden und das funktioniert definitiv

Zeno 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.

: Bearbeitet durch Moderator
von c-hater (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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?

von udok (Gast)


Lesenswert?

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?

von udok (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Leerzeichen (Gast)


Lesenswert?

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.

von wombles (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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:
1
mkdir c:\datadrive
2
mountvol c:\datadrive \\?\Volume{789ddf93-8c56-11db-9ebe-806d6172696f}
3
4
mountvol
5
...
6
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.

: Bearbeitet durch User
von wombles (Gast)


Lesenswert?

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.

von udok (Gast)


Lesenswert?

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

von udok (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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?

von c-hater (Gast)


Lesenswert?

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...

von René H. (mumpel)


Lesenswert?

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.

von wombles (Gast)


Lesenswert?

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
4
Copyright (C) 2000-2002 Mark Russinovich
5
Systems Internals - http://www.sysinternals.com
6
7
C:\Documents and Settings: JUNCTION
8
   Print Name     : C:\Users
9
   Substitute Name: C:\Users

Aber Lesen kannst du vermutlich auch nicht.

von Udo K. (udok)


Lesenswert?

Yalu X. schrieb:
> Wie würdest du das konkret im obigen Beispiel machen?

MS nmake kann damit umgehen.  Einfach den Namen in Anführungszeichen 
setzen.
1
SRC = f1.cpp "f 2.cpp"
2
mylib.lib: $(SRC)
3
  cl -nologo -O1 -c $(SRC)
4
  lib -nologo -out:$@ $(SRC:.cpp=.obj)

Gruss,
Udo

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Udo K. (udok)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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".

von Udo K. (udok)


Lesenswert?

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.

von grundschüler (Gast)


Lesenswert?

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.

von Alexander (alecxs)


Lesenswert?

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)

von Stefan F. (Gast)


Lesenswert?

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.

von Mat. K. (matthias_kornfield)


Lesenswert?

Die Lösung für mich war:
in windows über ein symbolic link zu erstellen: mit mklink.

mklink /j "C:\arm_tools_eclipse" "C:\Program Files\arm tools\..."

von S. R. (svenska)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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).

von S. R. (svenska)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.