Hi, ich versuche gerade, auf meinem Mac (mit neuestem macOS) eine globale Umgebungsvariable zu setzen, die von jeder Anwendung genutzt werden kann, also nicht nur vom Terminal. Das Problem ist jetzt, dass es im Internet dazu zig verschiedene Anleitungen gibt mit verschiedenen Wegen, weil Apple den Weg dafür scheinbar alle paar Versionen ändert. Und ich habe einfach keine Ahnung, welche Anleitung ich benutzen muss, und ich habe keine Lust, alle durchzuprobieren und mir mein System vollzumüllen.
Meine Frage jetzt: Wie setze ich in macOS 10.14 Mojave eine globale Umgebungsvariable, die von jeder Anwendung gelesen werden kann?

Globale Umgebungsvariable? Wie unter DOS? Oder Windows?

Wenn es von der App respektiert wird:

Kannst Du ein Beispiel nennen, wie Du das einsetzen willst?

Ich nutze Typinator als Textexpansions-Tool. Das bietet auch die Möglichkeit, mit Variablen zu arbeiten. Und das funktioniert in nahezu allen Programmen. Es gibt nur wenige Ausnahmen, wie z. B. Passwort-Eingabefelder, wo das Tool nicht greift.

EDIT: Diese Variablen kann ich dann per Kürzel abrufen. Ich habe zum Beispiel eine Abfrage für temporäre Variablen angelegt: Tippe ich ??# kann ich einen Wert für meine temporäre Variable eingeben. Einsetzen kann ich sie dann überall mit v#. Die kann ich so lange verwenden, bis ich den Wert neu vergebe.

Ich weiß nicht, ob diese Vorgehensweise Dir hilft …

Früher gab es die Datei ~/.MacOSX/environment.plist, diese funktioniert aber schon seit einigen Versionen nicht mehr. Es sollte aber noch funktionieren wie hier beschrieben. Der Tipp ist aber auch schon älter und könnte mittlerweile stillgelegt worden sein.
Der Grund der häufigen Änderungen ist, dass es einige Angriffe gibt, die durch gezieltes Setzen von Environment-Variablen durchgeführt wurden. Daher ist das in einigen Fällen als Sicherheitslücke anzusehen. Apple ist daher auch dazu über gegangen, dass Umgebungsvariablen per Finder gar nicht mehr an Anwendungen durchgereicht werden, bzw. nur noch ausgewählte. Das betrifft vor Allem Anwendungen, die App-Sandboxing verwenden.

Dein Anwendungsfall mag legitim sein - aber das kann auch missbraucht werden, daher sollte man Umgebungsvariablen nur bedingt nutzen.

Da müsstest Du schon spezifischer werden, was genau Du mit welcher App erreichen willst. In der allgemeinen Form, in der Du das bescheibst, gab es das auf macOS nie. Du kannst natürlich wie eh und je auch in Mojave Unix-Umgebungsvariablen setzen, die dann von Unix-Prozessen genutzt werden können, die von der Shell gestartet werden (egal, ob von Terminal aus, einem Skript oder was auch immer). Aber Cocoa-Programme haben diese Variablen im allgemeinen noch nie ausgewertet.

Ein Beispiel wäre die umask, mit der Du angibst, welche Lese- und Schreibrechte neu angelegte Dateien haben sollen. Unix-Programme richten sich danach, Cocoa-Programme aber nicht. Für die gab (gibt?) es einen globalen defaults-Parameter, (aus der Erinnerung) NSUmask. Aber ob ein Cocoa-Programm sich danach wirklich richtet, hängt von dessen Programmierung im Einzelfall ab.

Also ohne genauere Beschreibung Deinerseits, was Du erreichen möchtest, ist eine Antwort schwierig.

<hüstel/> Diese Erinnerung war komplett daneben, das ist Schnee von vorvorgestern. Da hat mir mein Langzeitgedächtnis („Aber eben war es doch noch so“) einen Streich gespielt, sorry.

Dennoch wäre es sinnvoll, wenn Du näher beschreibst, was genau Du erreichen willst.

Versuche es mal mit:

Verfizieren kannst Du das Ergebnis mit:

Wenn Du danach Terminal beendest und neu startest (das ist wichtig!), kannst Du auch mittels
prüfen, ob es funktioniert hast. Alle Applikationen, die Du nach der Einstellung startest, kennen die Environment-Variable dann (welche, die schon laufen, erst beim nächsten Starten).

Ich habe jetzt allerdings nicht überprüft, ob die Einstellung auch einen Neustart überlebt.

Da macOS scheinbar keine simple Möglichkeit dazu anbietet wie Windows (mal ein Punkt, den Microsoft definitiv besser gelöst hat), kurz der Anwendungsfall. Ich nutze die Anwendung "Nativescript Sidekick" für die Entwicklung. Damit das Programm allerdings den iOS-Simulator oder Android-Simulator benutzen kann, braucht es die JAVA_HOME Umgebungsvariable, die der offizielle Oracle-Java-JDK-Installer leider nicht setzt.
Der ganze "im Terminal" Krempel bringt hier also nichts, den auch habe ich auch schon durchprobiert. Meinetwegen würde es auch reichen, wenn die Variable auch nur für die eine Anwendung zur Verfügung steht, das ist egal. Falls es hilft: Sidekick ist eine Electron Anwendung.

aMacUser:

$ man java_home

MTN 2014, mein Beitrag von 31.07.2014, 22:58 Uhr: JAVA_HOME Variable setzen

Apple Developer: Technical Q&A QA1170: Important Java Directories on Mac OS X $JAVA_HOME

Zudem wiederholt es auch:

Oracle: Java Platform, Standard Edition Installation Guide, Installation of the JDK and the JRE on macOS: (Einiges davon ist veraltet bzgl. aktueller JDKs, das mit JAVA_HOME ist aktuell)

Usage for bash-style shells:
$ export JAVA_HOME=`/usr/libexec/java_home`

Usage for csh-style shells:
% setenv JAVA_HOME `/usr/libexec/java_home`


In Deiner ~/.bash_profile also bzgl. eines aktuellen JDK12:


That's it.

Ich erlaube mir hier mal anzumerken, wie wichtig es ist, Fragen ausreichend präzise zu stellen.

Es geht Dir um die JAVA_HOME Umgebungsvariable in einer ganz bestimmten Anwendung, die zudem keine Cocoa-Anwendung ist. Warum fragst Du das nicht schlicht, sondern fabulierst über "im Terminal" Krempel und jedwede Mac-Anwendungen?

Mit dem Terminal hat das alles überhaupt nichts zu tun. Das Terminal ist doch lediglich ein Kommandozeileninterface für den Unix-Unterbau von macOS; ob man Einstellungen im Unix-Unterbau mit dem Kommandozeileninterface Terminal oder einer entsprechenden GUI-App vornimmt, ist für den Effekt völlig egal. Also klang Deine Frage danach, wie Einstellungen in diesem Unix-Unterbau generell so vorgenommen werden können, dass sie von allen Mac-Apps, und das sind, wenn nichts anderes gesagt wird, Cocoa-Apps, berücksichtigt werden.

Darum kreisten mehr oder weniger alle Antworten. Es haben sich also mehrere Leute völlig umsonst Mühe gegeben, weil Du dir nicht die Mühe gemacht hast, Dein Problem hinreichend genau zu beschreiben (und auf entsprechende Nachfragen auch nicht rasch reagiert hast) und Dich auch noch in Genervtheiten wie Krempel und zumüllen geflüchtet hast. Das ist dann eher suboptimal.

Weia es tut mir leid, dass ich nicht der macOS-Darwin-Unix-Gott bin, den du erwartet hast. Und ich fabuliere auch nichts, wie du es nennst, ich habe es nur unkonventionell ausgedrückt. Und ich habe auch nichts anderes geschrieben, dass ich eine beliebige Umgebungsvariable in einer beliebigen Anwendung haben möchte, wer das nicht versteht, ist selbst dran Schuld.
Und natürlich hat das alles mit dem Terminal nichts zu tun, scheinbar bin ich der einzige, dem das von Anfang an klar war. Ich habe ja nicht umsonst geschrieben, dass ich die Variable überall nutzen will, und eben nicht nur im Terminal (was meine Formulierung impliziert hat). Das trotzdem fast nur "im-Terminal"-Antworten kamen, könnte daran liegen, dass viele Menschen nicht mehr genau den Startpost lesen (was leider ein sehr weit verbreitetes Phänomen im Internet ist).
Und ob ich die Variable jetzt einer nativen Anwendung, die das Electron-Framework nutzt, brauche, oder in einer nativen Anwendung, die ich selbst geschrieben habe, sollte am Ende nicht wirklich eine Rolle spielen. Den beide laufen nicht im Terminal. Und ob die Variable jetzt JAVA_HOME oder FOO_BAR heißt, ist auch so ziemlich egal.
Das Apple kein vernünftige und einheitliche Schnittstelle für globale Umgebungsvariablen hat, da kann ich auch nichts für, also beschere dich bitte nicht bei mir, dass ich davon ausgegangen bin, dass es sowas gibt.

sierkb die Lösungen mit export und setenv ja nur im Terminal. Und wie Weia festgestellt hat (und wo ich nie etwas anderes geschrieben habe), hat mein Anwendungsfall nichts mit dem Terminal zu tun.

Nochmal für alle, da einige scheinbar nicht lesen können: Ich brauche die Variable nicht im Terminal! Ich brauche sie in einer Desktop-Anwendung!

PS: Weia, bitte beschwere dich nicht wieder, wenn dir meine Ausdrucksweise nicht passt, denn nichts von deinem Kommentar hat dem Startpost widersprochen

PPS: Warum muss sich eigentlich immer jemand überall über Formulierungen beschweren? Reicht es nicht, einfach auf die Frage zu antworten?

Solltest Du meine Antwort nicht verstanden haben, lies sie einfach nochmal.

Setzen mußt Du die Variable im Terminal ("lauchctl ..."). Gültig ist sie dann in allen Applikationen, die per launchctl gestartet werden.

Beispiel:


Nun z.B. BBEdit starten und dann:


"ps eww" gibt Dir die Environment-Variablen für einen Prozeß mit aus. Wie Du an dem Eintrag "TEST=test" siehst, ist die per "launchctl setenv" gesetzte Environment-Variable für den BBEdit-Prozeß gesetzt.

Nachtrag: Die per "launchctl setenv" gesetzte Environment-Variable überlebt einen Neustart nicht. Die Einstellung muß beim Systemstart jeweils neu gesetzt werden.

Ich habe nirgendwo geschrieben, dass ich das erwartet habe.

Das wäre eine seltsame Erwartung, denn dann hättest Du ja Deine Frage nicht.
Eben. Und das stimmt nicht. Du willst eine ganz bestimmte Umgebungsvariable in einer ganz bestimmten Anwendung haben. Warum fragst Du dann nicht genau das?
Aber woher willst Du wissen, dass das alles egal ist, wenn Du doch kein macOS-Darwin-Unix-Gott bist? Schreibe doch, was Du wissen möchtest, und nicht etwas viel allgemeineres, von dem Du nur mutmaßt, dass es dasselbe wäre.
Nein, Du hast es schlampig und unpräzise ausgedrückt.
Weil schlampige Formulierungen den anderen unnötige Arbeit aufbürden und das rücksichtslos ist. Warum sollen die, die Dir helfen wollen, sich jeder für sich die Mühe machen sich zusammenzureimen, was eigentlich Dein Problem ist, statt dass Du, der die Hilfe will, Dir einmal die Mühe machst, das Problem präzise zu formulieren?
Wenn man sie verstehen könnte, dann ja.
Doch. Du hast Dein spezifisches Problem nicht klar formuliert.
Aber nur scheinbar (im Gegensatz zu anscheinend), denn es ist Dir ja noch nicht einmal jetzt klar:Nein, das liegt daran, dass Du offenbar noch immer nicht begreifst, dass die Tatsache, dass eine Lösung eine bestimmte Eingabe im Terminal vorschlägt, nichts damit zu tun hat, ob diese Änderung am System dann für Befehle im Terminal wirksam ist oder an anderen Stellen von macOS oder beides.

Du verwechselst unentwegt das UI zur Vornahme einer Änderung mit dem Wirkradius dieser Änderung. Wenn ich Dir jetzt eine Cocoa-App schreiben würde, die die erforderliche Änderung vornimmt, und Du klickst auf den Button dieser App, wäre dann irgendetwas anders, als wenn Du diesen Befehl in der App Terminal selbst eingeben würdest?

So allgemein geantwortet, wie Du gefragt hast:

Alles was aus einer Shell gestartet wird (völlig egal, ob nun im Terminal oder nicht), wertet /etc/profile bzw. /etc/bashrc aus.

Alles, was von launchd gestartet wird, wertet launchd.plists aus.

Ob Deine App von (wie allgemein üblich und bei Cocoa-Apps immer) launchd oder aber einer Shell gestartet wird, hängt von Deiner App ab.

Ob Deine App dann die Umgebungsvariablen überhaupt auswertet, hängt von Deiner App ab.
Sagt wer?
Gibt es doch.

Du musst den Befehl nur wie üblich in eine launchd.plist setzen, um ihn persistent zu machen:

Der Umweg über "sh" ist überflüssig, und Kommandos in Scripten sollten aus Sicherheitsgründen grundsätzlich immer mit vollem Pfad angegeben werden (sonst ist das Script anfällig für manipulierte PATH-Variable und Aliases).

Ich würde das also eher so lösen:

Da hast Du natürlich zu 100% recht.

Ich hatte das übereilt aus einer real existierenden Datei kopiert, ohne groß drüber nachzudenken – sorry!

Der Umweg über sh ist, wenn ich das richtig überblicke, die beste Lösung, wenn man mehr als eine Umgebungsvariable setzen will – im Shell-Skript ginge das einfach mit mehreren Zeilen, aber bei direktem Aufruf von launchctl setenv müsste man wohl mehrere launchd.plists anlegen – das wäre eher unschön. Aber auch dann bleibt natürlich Dein Hinweis gültig, dass man /bin/sh und nicht nur sh angeben sollte.

aMacUser:

Haste es ausprobiert wie ich Dir geraten habe? Oder haste es unausprobiert vom Tisch gewischt?

So wie ich es beschrieben und verlinkt habe, ist es er offiziell von Apple vorgesehene Weg! Für Terminal UND Desptop-Anwendungen. Apple hat dazu extra ein Helper-Programm ersonnen, nämlich /usr/libexec/java_home. In früherer Zeit gab es dazu ein entspr. Control Panel in den Systemeinstellungen, um zwischen verschiedenen existierenden Java-Installationen auszuwählen bzw. dort auf diese Weise JAVA_HOME zu setzen, das ist weggefallen.

Deswegen soll sie ja auch in der Konfigurationsdatei für eine login Shell, in ~/.bash_profile gesetzt werden und nicht in der Konfigurationsdatei für eine non-login Shell, ~/.bashrc.
Q:

macOS ist ein Unix. Wenn Du Deinen Rechner hochfährst, startest, startet das System non-interaktive Shells für alle möglichen Prozesse, wenn Du Dich dann einloggst am Bildschirm, startet das System weitere Shells unter diesem dann eingeloggten Nutzer, während sich der Bildschirm aufbaut. Dort, an dem Ereignispunkt werden i.d.R. dann auch nutzerspezifische Umgebungsvariablen gesetzt, während vor dem Einloggen globale Umgebungsvariablen abgehandelt wurden. Genau hier, an der Stelle kannste dann u.a. Dein $JAVA_HOME setzen, wie ist obig beschrieben. Und da kommt es dann sehr drauf an, in welche Konfigurationsdatei man das dann reinschreibt und ob's nur bei einer Login-Shell via Terminal wirkt oder globaler und darüber hinaus (auch GUI-Anwendungen weren unter der Haube via einer Shell gestartet!).

Wenn Du ein Terminal öffnest, eröffnest Du bzw. das System ebenfalls eine Shell, diesmal eine interaktive Shell. Eine interaktive Shell ist hier von Dir aber nicht gefragt, sondern es soll gleich beim/nach dem Hochfahren gesetzt werden, da ist ein Terminal noch gar nicht erreichbar. Deswegen: ~/.bash_profile. Die wird vom System sofort in dem Moment abgearbeitet, ab Deinem ersten Einloggen im System, und das ist beim Hochfahren des Systems.

Wenn das so nicht funktionieren sollte, evtl. eine Kombination aus

export JAVA_HOME=`/usr/libexec/java_home`

launchctl getenv $JAVA_HOME
bzw.
launchctl setenv JAVA_HOME `/usr/libexec/java_home`

in der betreffenden Plist-Datei der Anwendung?
?

Also ich habe sowohl export als auch launchctl ausprobiert und beide wirken sich nur im Terminal aus, auch über den plist Weg, damit es den Neustart überlebt.

Edit: vielleicht habe ich ja auch irgendwas übersehen dabei, bei den Dutzenden Möglichkeiten (und Apples regelmäßigen Änderungen daran) verliert man schonmal den Überblick.

aMacUser:

Und das Setzen von LSEnvironment / und Zuweisen des entspr. Wertes in der betreffenden Plist-Datei Deiner Anwendung?

Zusatzfrage:

Hast Du ~/.bash_profile in ~/.bashrc gesourced bzw. umgekehrt, sodass jeweils die Eine die Andere auch mitzieht beim Verarbeiten, egal, welche von beiden vom System bzw. beim Starten von Shells abgearbeitet wird?

In der Anwendung setzen habe ich noch nicht probiert, allerdings habe ich gelesen, dass der Weg seit ein paar Versionen wohl eh nicht mehr geht (daher hatte ich ihn direkt verworfen). Wenn ich morgen Abend wieder am Rechner bin, kann ich das aber trotzdem mal probieren.

Ist denn überhaupt sicher, dass die fragliche App das Environment ordnungsgemäß auswertet?

Das kannst Du prüfen, indem Du in einer Terminal-Shell zunächst die Environment-Variable setzt und dann das Programm direkt aus der Shell mit Eingabe von Pfad und startest:


Wenn das Programm dann noch immer nicht so reagiert, wie Du wünscht, dann liegt das Problem darin, dass es diese Environment-Variable überhaupt nicht berücksichtigt.

Was ich auch nicht verstehe: Dieses Programm ist ja offenkundig genau und ausschließlich dazu gedacht, iOS-Programme zu schreiben, d.h., Dein Problem hat jeder, der das Programm unter macOS nutzt. Da muss es doch eine Dokumentation dazu geben oder zumindest Hilfe von Support und/oder Community?

"export ..." funktioniert wirklich nur, wenn der Prozeß aus einer Shell heraus gestartet wird. Das ist bei moderner Software unter macOS eher die Ausnahme.

Es gibt verschiedene Gründe, warum es per "launchctl" schiefgehen kann.

1. Die Änderung kommt nur in nach dem Setzen der Environment-Variable per launchctl gestarteten Applikationen an. Was zum Zeitpunkt des Setzens schon lief, sieht sie nicht.

2. Die Domain der Variable muß stimmen. z.B. für systemweite Prozesse mußt Du sie per "sudo launchctl ..." setzen (und die Prozesse dann neu starten), für benutzereigene Prozesse einfach per launchctl vom betreffenden User aus.

3. Dann muß die Applikation die Environment-Variable auch noch beherzigen und nicht einen eigenen Wert dafür setzen.

* Kannst Du die PID Deines Applikationsprozesses ausfindig machen und dann per "ps eww" nachsehen, ob die Variable gesetzt ist? Wenn die Variable für den Prozeß gesetzt ist und er sie dennoch nicht berücksichtigt, ist vermutlich der dritte Fall eingetreten.

* Was siehst Du bei Eingabe von "sudo launchctl getenv JAVA_HOME", was bei "launchctl getenv JAVA_HOME"?

* Was wird ausgegeben, wenn Du "sudo launchctl [Name Deiner plist]" bzw, "launchctl [Name Deiner plist]" eingibst?

* Brauchst Du wirklich nur JAVA_HOME? Meist will Java auch noch den PATH um "$JAVA_HOME/bin" (oder ähnliches, je nach Installation) erweitert haben.

* Wo hast Du die plist zum Setzen Deiner Environment-Variable hingestellt? ~/Library/LaunchAgents oder anderswo?

So oft hat sich das gar nicht geändert.

Der uralte cut&paste-Fluch
Alternativ kann man die zu setzenden Variablen in ein separates Shell-Script packen und dann das von der plist aus aufrufen. Wenn viele Variablen zu setzen sind, ist das meist übersichtlicher als ein ewig langes Shell-Konstrukt in der XML-Datei. Aber ein wenig ist das natürlich auch Geschmacksache.

Dazu:

NativeScript Core: NativeScript Advanced Setup: macOS
NativeScript Core: NativeScript Advanced Setup: macOS: Advanced Setup Steps

Etc.


Kennst Du dieses Dokument (da steht nicht nur was zu JAVA_HOME drin sondern auch vorher und nachher zu .bash_profile und was da reinzuschreiben und wie damit umzugehen ist)? Hast Du es gelesen und so umgesetzt wie es da steht?

Wenn das nicht klappt – was sagt der NativeScript Support bzw. deren Support Forum?

Zudem stoße ich mich grad' etwas an dem einleitenden Satz "On macOS systems, you can use the NativeScript CLI to develop Android and iOS apps." Ich betone nochmal: CLI (Command Line Interface). Warum steht da explizit CLI bzw. ein Hinweis drauf? Geht's evtl. nur so, ist die Entwicklung mit der NativeScript Software auf dem Mac evtl. nur so vorgesehen – für die CLI-Nutzung? Frag' den Support.

Weia @@Peter Eckel Ich habe jetzt den Weg ausprobiert, die Variable im Terminal zu setzen und dann Sidekick in der selben Sitzung zu öffnen (das ich nicht selbst drauf gekommen bin, unter Windows mache ich das ständig ^^). Gesetzt ist die Variable für den Prozess, aber die Anwendung ließt sie scheinbar nicht korrekt aus.

sierkb Auf der Seite war ich zwar, habe aber nicht so weit gelesen, da ich den Android-Teil erstmal nicht brauche. Dort wird allerdings auch nur export vorgeschlagen. Der Part mit dem bash_profile ist ja auch für Terminal-Sitzungen. Es kann natürlich durchaus sein, dass die Anwendung im Hintergrund nodejs auf cmd-Ebene nutzt, wo ich bisher gedacht habe, dass es nicht so ist. Denn offensichtlich ließt die Anwendung die Umgebungsvariablen sowieso nicht korrekt aus (siehe oben). Dann bringt natürlich jegliches Setzen irgendwo nichts.

Edit: Die Nativescript CLI funktioniert bei mir aus anderen Gründen nicht (was mich sowieso schon nervt).

NativeScript Sidekick: Set Up Your System and Install Sidekick :

sierkb Auch wenn du es glaubst, bin ich nicht zu blöd, eine Anleitung zu lesen. Ich habe alles nach Anleitung installiert. Das die Anleitung und Anwendung fehlerhaft ist, ist nicht mein Fehler, das ändert sich auch nicht, indem du die Anleitung hier rein kopierst. Falls du die Anleitung gelesen haben solltest, wüsstest du, dass dort in der macOS-Anleitung oben drin steht, dass JAVA_HOME zwar verfügbar sein muss, aber nicht wie. Und weiter unten (wo es um die Android-Requirements geht, die ich nicht brauche) steht, man solle export verwenden, was nachweislich nicht funktioniert. Du kannst mich gerne so oft für blöd halten, wie du willst, aber an der fehlerhaften und schlecht aufgebauten Anleitung ändert das nichts.
Und hättest du meinen Post komplett gelesen, wüsstest du, dass die fehlende Variable noch nichtmal das Problem ist, sondern ein Programmfehler, wodurch die Variable nicht korrekt ausgelesen wird. Und da hilft die Anleitung (die ich ja schon befolgt hatte, bevor ich hier überhaupt irgendwas geschrieben hatte) auch nicht mehr viel.

aMacUser:

Dein überaus freundlicher Tonfall ist einnehmend, Weia hat auch schon was (eher indirekt) dazu gesagt.
Bitteschön fürs Helfen. Gern geschehen. Nichts zu danken.

Die Anleitung stumpf ohne Kommentar hier rein zu kopieren, obwohl ich die logischerweise schon durchgeführt habe (da sonst Sidekick noch nichtmal gestartet wäre), war natürlich äußerst nützlich

Jetzt reicht es aber langsam wirklich! Hör auf, hier Leute und namentlich sierkb anzumachen, die Dir helfen wollen!

Verbockt hat das niemand anderes hier, sondern Du allein. Statt vor einem Post ins Forum selbständig den Fehler einzugrenzen und somit festzustellen, dass das Programm aufgrund eines Bugs die Umgebungsvariablen ignoriert und das ganze hier verhandelte Problem in Wirklichkeit gar nicht existiert, machst Du – wie sich nun herausstellt, völlig unnötigerweise – einen Thread im Forum auf, formulierst Dein Problem so vage, dass niemand hier präzise helfen kann, und lässt stattdessen Deinem Frust freien Lauf (keine Lust, vollmüllen) – sollen sich doch die anderen für Dich Mühe geben.

Das tun sie auch und fragen aufgrund der vagen Problemstellung nach, worauf sie erstmal zwei Tage keinerlei Antwort von Dir erhalten. Also zerbrechen sich alle unnötig die Köpfe. Dann wirst Du endlich spezifischer, beschwerst Dich aber gleichzeitig, dass Du nicht einfach nur die Antwort auf Deine Frage geliefert bekommst. Weiteres gemeinsames Rätselraten, und am Ende stellt sich heraus, dass das Problem an ganz anderer Stelle liegt und sich mehrere Leute völlig umsonst Arbeit für Dich gemacht haben, weil Du eingangs den Fehler nicht eingegrenzt hast. Und dann hast du auch noch die Stirn, sierkb, der Dir geduldig weitere Hinweise geben will, anzumachen? Das kann ja wohl nicht wahr sein!

Falls hier jemand den Eindruck bekommen haben sollte, dass Du zu blöd seist, eine Anleitung zu lesen, dann hättest Du dir das mit Deinem Kommunikationsverhalten ganz allein zuzuschreiben …

aMacUser:

Anderen Ton bitte (siehe MTN Nutzungsbedingungen)! Ich habe Dir nix getan und bin Dir gegenüber auch freundlich, geduldig und hilfsbereit im Ton! Ich will nur nett sein und Dir bei der Lösung Deines Problems helfen! Und wenn Du selber einräumst, bestimmte relevante Dokumente noch nicht mal zu Ende gelesen zu haben, sei der dezente leise Hinweis darauf erlaubt sein bzw. die Nachfrage, ob Du das alles so beherzigt hast, was da steht, genau den Eindruck machst Du nämlich trotz Deiner Polterei bisher leider nicht! Für Deinen Frust kann ich nix! Lasse ihn bitte woanders raus aber nicht her bzw. an mir, dann nimm Dir dazu einen Box-Sack o.ä!
Entschuldigung, dass ich Dir gegenüber überhaupt mir die Zeit und Mühe mache und geduldig zu helfen versuche!
Dann wende Dich doch bitte zielgerichtet ans NativeScript Support- und User-Forum, da kriegste zielgerichtet zu Deinem Problem auch eine Antwort, das wäre sowieso die geeignetere Ziel-Adresse bei so einer Frage als so ein Produkt-fremdes Forum wie MTN. Benutzen wir NativeScript Software oder Du?

Sonst noch jemand, der die Hälfte meiner Posts ignoriert? Ja, vielleicht war mein Ausgangspost zu unscharf formuliert. Aber dann wurde ich von euch direkt angemeckert. Dann habe ich mein Problem genauer beschrieben, und vielleicht hätte ich es auch da besser formulieren können. Aber anstatt nett zu antworten, wurde ich von euch nur noch mehr angemeckert. Und da ihr scheinbar von Anfang an meine Post nicht genau gelesen habt (ich habe ja kaum etwas neues geschrieben, sondern nur das bereits vorhandene anders formuliert), rege ich mich halt etwas auf.
Ich habe Hilfe gesucht, und ein paar Leute haben auch versucht zu helfen, aber andere waren der Meinung, direkt auf von mir blöd formulierten Sätzen rumzuhacken. Wenn ihr euch beschwert, dass ich nicht ganz freundlich bin, dann fasst euch erstmal an eure eigene Nase. Ihr mögt ja zwischendurch hilfreiche Sachen geschrieben haben, aber dabei habt ihr es immer so formuliert, als wäre ich ein Trottel, der keine Anleitungen lesen kann und keine Ahnung von der Materie hat. Ja, ich habe vielleicht nicht die maximale Ahnung von dem Thema, aber trotzdem muss man nicht gleich deswegen rum meckern.
Aber sei es wie es sei, ich suche mir meine Hilfe einfach wo anders, hier meckert man ja scheinbar nur rum, wenn der Startpost nicht perfekt Formuliert ist und man nicht erst eine dreiwöchige Schulung in dem Thema gemacht hat. Sorry, aber genau so habt ihr euch mir gegenüber verhalten.

aMacUser:

NativeScript: Troubleshooting
NativeScript: Troubleshooting: Known Issues

GitHub NativeScript: Issues

Ist Dein Problem darunter? Wenn nein, eröffne im Issue-Tracker doch mal einen Issue und warte auf Antworten. Bzw.

aMacUser:

sirkb Zu deiner ersten Antwort: Nein, da ist mein Problem nicht drunter. Ich habe mich vorher natürlich im Internet erst informiert, ob das Problem bekannt ist (mir wurde hier ja nicht nur einmal unterstellt, dass ich das nicht getan hätte).
Zu deiner zweiten Antwort: Ich kenne die Regeln. Und nebenbei wart ihr zuerst unfreundlich. Zumindest von meinem Standpunkt aus. Ich habe nur vielleicht ungenau formuliert (wobei es von meinem Standpunkt aus glasklar ist). Ihr habt mich daraufhin ohne ersichltichen Grund unfreundlich deswegen angemeckert. Das kannst du oben gerne nachlesen.
In meinen Antworten habe ich jeweils versucht die Lage klarzustellen. Eure Post hingegeben sind, wie ich es sehe, voll von unwahren Anschuldigungen.

Ich bin dann hier fertig und werde nicht mehr antworten. Wir würden eh nicht mehr zum Thema kommen, da ihr nur noch ein Interesse daran habt, mich anzuschuldigen.

Interessant:

GitHub: NativeScript Issue #2506 (Closed): Install creates .bash_profile if it doesn't exist on Mac
verweist dazu am Schluss auf:
GitHub: NativeScript-CLI #1949 (Closed): Install creates .bash_profile if it doesn't exist on Mac
verweist dazu am Schluss auf:
GitHub: NativeScript Issue #1358 (Closed): Webstorm Ubuntu .bash_profile (Remove .bash_profile alter for autocomplete)

Sprich: die Software hat zumindest mal selber automatisch eine ~/.bash_profile gesetzt gehabt, in der per
export die Umgebungsvariablen $ANDROID_HOME und $JAVA_HOME gesetzt wurden. Inzwischen muss man das zwecks Vermeidung von Problemen (siehe die Beschreibung und Diskussion in den genannten Issues) wohl selber händisch tun (siehe obig genannte Installations-Dokumente). Und offenbar gilt das für NativeScript Desktop-Software wie für NativeScript CLI Software, wobei die NativeScript Desktop-Software das Vorhandensein der NativeScript CLI Software offenbar zwingend voraussetzt, um einwandfrei funktionieren zu können (sagt die Installations-Doku ja auch so).

Ich habe mir mal testweise von hier
NativeScript Sidekick Download die Mac-Version als .dmg runtergeladen und bei mir in ~/Applications per Drag&Drop reinkopiert. Und dann gestartet.
Folgendes zeigt es mir beim Start:


In Worten:
Ich installiere die Komponenten nicht, breche hier ab. Was ich aber mache:
NativeScript Sidekick Help Show Logs.

Es öffnet sich ein Finder-Fenster, zeigt mir zwei Log-Dateien, die es bis dahin geschrieben hat:

/Users/$USER/Library/Application Support/NativeScriptSidekick/Logs/console_19-05-06_01-12-48. 765.log
/Users/$USER/Library/Application Support/NativeScriptSidekick/Logs/main_19-05-06_01-12-51.874 .log

Und da habe ich mal neugierig reingeschaut. Und es eröffnet mir Erstaunliches: zuerst versucht es das per Node.js, da das aber nicht installiert ist, probiert es das anders und hat Erfolg: das GUI-Programm NativeScript Sidekick findet bei mir nämlich auf Anhieb alle meine Umgebungsvariablen inklusive $JAVA_HOME und $PATH, welche bei mir in ~/.bash_profile gesetzt sind ($JAVA_HOME via export JAVA_HOME=`/usr/libexec/java_home -F -v 12`) und schreibt sie alle fein säuberlich in console_19-05-06_01-12-48.765.log:

Und main_19-05-06_01-12-51.874.log beschwert sich über alles Mögliche und das Fehlen von allem Möglichen, u.a. über das Fehlen von $ANDROID_HOME (kein Wunder, ist ja auch nicht gesetzt bei mir) aber ganz offenbar NICHT über das Fehlen von $JAVA_HOME (denn diese Umgebungsvariable ist bei mir seit Jahren gesetzt in ~/.bash_profile, und ganz offenbar hat NativeScript Sidekick sie auch zumindest bei mir gefunden, wenn ich diesen beiden von NativeScript Sidekick generierten Log-Dateien glauben darf):

Was und warum funktioniert bei mir offenbar, was bei aMacUser nicht klappen will – nämlich, dass das GUI-Programm NativeScript Sidekick (ohne dass das notwendige Node.js installiert ist, ohne dass das notwendige npm installiert ist, ohne dass das notwendige NativeScript CLI installiert ist) meine via ~/.bash_profile gesetzte $JAVA_HOME Umgebungsvariable bereits beim allerersten Start offenbar doch gefunden hat? Was habe ich anders gemacht als aMacUser? Oder irre ich, wo ist der Fehler meinerseits? Wieso findet er bei mir $JAVA_HOME? Nach aMacUser dürfte das ja angeblich nicht sein, weil per ~/.bash_profile gesetzt und somit seiner Ansicht nach irrelevant und wirkungslos, oder? Wie kann das sein? Oder wo ist mein Fehler/Denkfehler? Bin verwirrt. *AmKopfkratz*