Forum>Entwickler>Globale Umgebungsvariable setzen in macOS 10.14 Mojave

Globale Umgebungsvariable setzen in macOS 10.14 Mojave

aMacUser
aMacUser01.05.1922:34
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?
-3

Kommentare

sunni02.05.1908:25
Globale Umgebungsvariable? Wie unter DOS? Oder Windows?

Wenn es von der App respektiert wird:
export myVar="myContent"
„*Dieser Tag kann Spuren von Müssen enthalten.“
0
udrabo
udrabo02.05.1908:54
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 …
0
ssb
ssb02.05.1910:29
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.
0
Weia
Weia02.05.1914:09
aMacUser
Meine Frage jetzt: Wie setze ich in macOS 10.14 Mojave eine globale Umgebungsvariable, die von jeder Anwendung gelesen werden kann?
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.
0
Weia
Weia02.05.1920:53
Weia
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.
<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.
0
Peter Eckel02.05.1921:25
Versuche es mal mit:
launchctl setenv VARIABLE "wert"

Verfizieren kannst Du das Ergebnis mit:
launchctl getenv VARIABLE

Wenn Du danach Terminal beendest und neu startest (das ist wichtig!), kannst Du auch mittels
printenv | grep VARIABLE
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.
0
aMacUser
aMacUser03.05.1919:14
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.
-1
sierkb03.05.1919:44
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:

export JAVA_HOME=`/usr/libexec/java_home -F -v 12`

That's it.
0
Weia
Weia03.05.1920:24
aMacUser
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
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.
+4
aMacUser
aMacUser04.05.1912:47
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?
-3
Peter Eckel04.05.1913:07
aMacUser
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!
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:

ardbeg:~ pete$ launchctl setenv TEST "test"

Nun z.B. BBEdit starten und dann:

ardbeg:~ pete$ ps -ef | grep -i bbedit
  501 70331     1   0  1:04PM ??         0:03.55 /Applications/BBEdit.app/Contents/MacOS/BBEdit
  501 70349     1   0  1:04PM ??         0:00.02 /Applications/BBEdit.app/Contents/XPCServices/BBShellCommand XPCService.xpc/Contents/MacOS/BBShellCommandXPCService
  501 70362 70310   0  1:04PM ttys001    0:00.00 grep -i bbedit

ardbeg:~ pete$ ps eww 70331
  PID   TT  STAT      TIME COMMAND
70331   ??  S      0:03.60 /Applications/BBEdit.app/Contents/MacOS/BBEdit TMPDIR=/var/folders/l5/ylhhbd794hq5gn5f5bfw6c2m0000gn/T/ __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 TEST=test HOME=/Users/pete SHELL=/bin/bash Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.fU 3gsdgGJs/Render SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.FAhiCqbaBz/List eners PATH=/usr/bin:/bin:/usr/sbin:/sbin LOGNAME=pete DISPLAY=/private/tmp/com.apple.launchd.Qt8ZWRzgg6/org.macosf orge.xquartz:0 XPC_SERVICE_NAME=com.barebones.bbedit.32048 USER=pete XPC_FLAGS=0x1

"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.
0
Peter Eckel04.05.1913:20
Nachtrag: Die per "launchctl setenv" gesetzte Environment-Variable überlebt einen Neustart nicht. Die Einstellung muß beim Systemstart jeweils neu gesetzt werden.
0
Weia
Weia04.05.1914:11
aMacUser
Weia es tut mir leid, dass ich nicht der macOS-Darwin-Unix-Gott bin, den du erwartet hast.
Ich habe nirgendwo geschrieben, dass ich das erwartet habe.

Das wäre eine seltsame Erwartung, denn dann hättest Du ja Deine Frage nicht.
Und ich habe auch nichts anderes geschrieben, dass ich eine beliebige Umgebungsvariable in einer beliebigen Anwendung haben möchte
Eben. Und das stimmt nicht. Du willst eine ganz bestimmte Umgebungsvariable in einer ganz bestimmten Anwendung haben. Warum fragst Du dann nicht genau das?
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.
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.
ich habe es nur unkonventionell ausgedrückt
Nein, Du hast es schlampig und unpräzise ausgedrückt.
PPS: Warum muss sich eigentlich immer jemand überall über Formulierungen beschweren?
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?
Reicht es nicht, einfach auf die Frage zu antworten?
Wenn man sie verstehen könnte, dann ja.
PS: Weia, bitte beschwere dich nicht wieder, wenn dir meine Ausdrucksweise nicht passt, denn nichts von deinem Kommentar hat dem Startpost widersprochen
Doch. Du hast Dein spezifisches Problem nicht klar formuliert.
Und natürlich hat das alles mit dem Terminal nichts zu tun, scheinbar bin ich der einzige, dem das von Anfang an klar war.
Aber nur scheinbar (im Gegensatz zu anscheinend), denn es ist Dir ja noch nicht einmal jetzt klar:
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).
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.
Das Apple kein vernünftige und einheitliche Schnittstelle für globale Umgebungsvariablen hat
Sagt wer?
also beschere dich bitte nicht bei mir, dass ich davon ausgegangen bin, dass es sowas gibt.
Gibt es doch.
+1
Weia
Weia04.05.1914:19
Peter Eckel
Nachtrag: Die per "launchctl setenv" gesetzte Environment-Variable überlebt einen Neustart nicht. Die Einstellung muß beim Systemstart jeweils neu gesetzt werden.
Du musst den Befehl nur wie üblich in eine launchd.plist setzen, um ihn persistent zu machen:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
<dict>
 <key>Label</key>
 <string>environment</string>
 <key>ProgramArguments</key>
 <array>
 <string>sh</string>
 <string>-c</string>
 <string>launchctl setenv TEST "test"</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
</dict>
</plist>
0
Peter Eckel04.05.1914:35
Weia
<?xml version="1.0" encoding="UTF-8"?>
[...]
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:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>setenv.TEST</string>
        <key>RunAtLoad</key>
        <true/>
        <key>ProgramArguments</key>
        <array>
            <string>/bin/launchctl</string>
            <string>setenv</string>
            <string>TEST</string>
            <string>test</string>
        </array>
    </dict>
</plist>
+1
Weia
Weia04.05.1915:00
Peter Eckel
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).
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.
+1
sierkb04.05.1915:01
aMacUser:

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

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!

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.
aMacUser
Ich brauche die Variable nicht im Terminal! Ich brauche sie in einer Desktop-Anwendung!

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.
Each Unix shell (sh, csh, etc.) can be in interactive mode or noninteractive mode. A shell also can act as a login shell or a nonlogin shell. A shell is a shell is a shell -- e.g., a login bash shell is the same program (like /bin/bash) as a nonlogin bash shell. The difference is in the way that the shell acts: which setup files it reads, whether it sets a shell prompt, and so on.
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?
?
0
aMacUser
aMacUser04.05.1916:05
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.
0
sierkb04.05.1916:10
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?
0
aMacUser
aMacUser04.05.1916:13
sierkb
aMacUser:

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

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.
0
Weia
Weia04.05.1916:46
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:

/Pfad/zu/NativeScript\ Sidekick.app/Contents/MacOS/NativeScript\ Sidekick

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?
+2
Peter Eckel04.05.1917:07
aMacUser
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.
"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?
aMacUser
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.

So oft hat sich das gar nicht geändert.
+1
Peter Eckel04.05.1917:12
Weia
Ich hatte das übereilt aus einer real existierenden Datei kopiert, ohne groß drüber nachzudenken – sorry!
Der uralte cut&paste-Fluch
Weia
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.
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.
0
sierkb04.05.1918:07
aMacUser
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…

Dazu:

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

This page contains a list of all system requirements needed to build and run NativeScript apps on macOS, as well as a guided walkthrough for getting these requirements in place. On macOS systems, you can use the NativeScript CLI to develop Android and iOS apps.

[…]

You must also have the following two environment variables setup for Android development:

JAVA_HOME
ANDROID_HOM

[…]

Advanced Setup Steps

4. Install the dependencies for Android development.

1. Set up JDK 8.

brew tap AdoptOpenJDK/openjdk

brew cask install adoptopenjdk8
1. Set the JAVA_HOME system environment variable.

export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)

2. Install the Android SDK.
[…]

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.
0
aMacUser
aMacUser05.05.1922:23
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).
+1
sierkb05.05.1922:59
aMacUser
sierkb Auf der Seite war ich zwar, habe aber nicht so weit gelesen […] 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.
[…]

NativeScript Sidekick: Set Up Your System and Install Sidekick :

NativeScript Sidekick
Set Up Your System and Install Sidekick

Step 1: Install Node.js

To run NativeScript Sidekick, you need to have Node.js installed on your machine.
To check whether Node.js is installed on your development machine, you should open a terminal or command prompt and run the node --version command. If you get an error, head to https://nodejs.org/ and download and install the latest Node.js LTS version. We recommend using Node.js 8.x.

Step 2: Install the NativeScript CLI

To run NativeScript Sidekick, you need to have the latest version of the NativeScript CLI installed on your machine. To install the latest version of NativeScript CLI from npm, you should open a terminal or command prompt and run the following command…

[…]

Step 3: Download and Install Sidekick

Download the installation file appropriate for your operating system:
Windows 64-bit
macOS 64-bit
Linux 64-bit

Step 4 (Optional): Install iOS and Android Requirements for Local Builds

If you plan on using only the Cloud build functionality, you should disregard this step.

To build locally with NativeScript Sidekick, you need to set up each platform you intend to build for on your development machine.

Set up a Windows machine
Set up a macOS machine (siehe obig bereits genanntes und verlinktes Dokument)
Set up a Linux machine

[…]
0
aMacUser
aMacUser05.05.1923:19
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.
-5
sierkb05.05.1923:28
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.
0
aMacUser
aMacUser05.05.1923:31
sierkb
aMacUser:

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
-3
Weia
Weia05.05.1923:36
aMacUser
sierkb Auch wenn du es glaubst, bin ich nicht zu blöd, eine Anleitung zu lesen […]
Und hättest du meinen Post komplett gelesen, wüsstest du […]
Und da hilft die Anleitung (die ich ja schon befolgt hatte, bevor ich hier überhaupt irgendwas geschrieben hatte) auch nicht mehr viel.
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 …
+4
sierkb05.05.1923:38
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?
+2
aMacUser
aMacUser06.05.1900:04
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.
-4
sierkb06.05.1900:06
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.
GitHub, NativeScript
[…]

Get Help

Please, use github issues strictly for reporting a bugs or requesting features . For general NativeScript questions and support, check out Stack Overflow or ask our experts in NativeScript community Slack channel .
0
sierkb06.05.1900:09
aMacUser:
MTN Nutzungsbedingungen
[…]

5. Spezielle Regelungen für die einzelnen Dienste

Forum:

Das Forum soll eine Plattform zur freien und kritischen Diskussion sein - in einem offenen und freundlichen Gesprächsklima. Diskutieren Sie fair und sachlich, auch wenn es mal zum Streit kommt.
[…]
Wählen Sie eine passende Überschrift bei den Beiträgen. Versuchen Sie schon im Titel, die Art des Problems zu beschreiben.

[…]

Noch einige Tipps!

  • Wer Fragen hat, sollte zunächst die Forumssuche verwenden, um herauszufinden, ob diese Frage schon einmal gestellt wurde. Damit lässt sich unter Umständen viel Zeit sparen. Außerdem sollte der Fragesteller auch bekannt geben, welche Lösungsversuche er schon unternommen hat, um nicht den Eindruck entstehen zu lassen, die komplette Arbeit auf die anderen Forumsmitglieder abwälzen zu wollen. Die Suchfunktion befindet sich in der Kopfleiste der Seite.
  • Bitte achten Sie auf Emoticons und machen selber Gebrauch davon! Der Zweck dieser Smileys ist es, eventuellen Missverständnissen vorzubeugen. Also nicht gleich angegriffen fühlen! Erst die Emoticons interpretieren. Häufig klingen Beiträge im Forum oder in den Kommentaren schärfer, als sie eigentlich gemeint waren. Bleiben Sie deswegen ruhig, auch wenn Sie sich angegriffen fühlen.
  • Ein sorgfältig formulierter Beitrag kann ebenfalls Missverständnissen vorbeugen. Bei Problemen verwenden Sie bitte eine möglichst aussagekräftige Überschrift und eine detaillierte Fehlerbeschreibung. Überschriften wie "Hilfe, mein Mac hängt" sind weniger geeignet. Fehlerbeschreibungen wie "Meine Platte will manchmal nicht so richtig. Wer kennt das?" sind ebenfalls wenig hilfreich. Mehrere Ausrufe- oder Fragezeichen gelten als unhöflich. Ein Threadtitel "Was kann ich tun???" sollte daher vermieden werden.
  • […]

[…]
0
aMacUser
aMacUser06.05.1900:35
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.
-3
sierkb06.05.1902:30
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:
Additional components are required to run NativeScript Sidekick

Click Install to automatically download and install the components listed below

  • NodeJS >=8.0.0
  • npm
  • NativeScript CLI >=5.2.3

[Install] [Quit] [Need help?]

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:
console_19-05-06_01-12-48.765.log
Unable to get environment variables from node, will try another approach.
#ENV: {"SHELL":"/opt/local/bin/bash","XPC_FLAGS":"0x0","JAVA_HOME":"/Library/Java/JavaVirtualMachines/jdk-12.0.1.jd k/Contents/Home","SSH_AUTH_SOCK":"/private/tmp/com.apple.launchd.mtLAcH7EEE/ Listeners","PWD":"/","LOGNAME":"johndoe","HOME":"/Users/john doe","TMPDIR":"/var/folders/c4/uuz6gess5r9drr0f64bcjqdr0000z q/T/","CLICOLOR":"1","USER":"johndoe","SHLVL":"1","XPC_SERVI CE_NAME":"com.progress.nativescriptsidekick.125260","PS1":"[\\s-\\v \\[\\e[0;32m\\]\\u@\\h\\[\\e[m\\] \\[\\e[1;34m\\]\\w\\[\\e[m\\]]\\[\\e[1;32m\\]\\$\\[\\e[m\\] ","GOOGLE_API_KEY"[unkenntlich gemacht]","Apple_PubSub_Socket_Render":"/private/tmp/com.apple.launc hd.jnmPBjANiD/Render","PATH":"/Users/johndoe/bin:/usr/local/ bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/us r/local/mysql/bin:/opt/local/bin:/opt/local/sbin:/usr/local/ bin:/usr/bin:/bin:/usr/sbin:/sbin:","HISTIGNORE":"&:[ ]*:exit:ls:bg:fg:history:clear","__CF_USER_TEXT_ENCODING":"0x 1F6:0x0:0x3","_":"/usr/bin/env"}

[…]

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):
main_19-05-06_01-12-51.874.log
[…]
[19-05-06 01:13:22.487] (Info) ab.tnsDoctor.shell.checkLocalBuild - {"iOS":{"canExecuteLocalBuild":false,"warnings":[{"warning":"WARNING: xcodeproj is not installed or is not configured properly.","additionalInformation":"You will not be able to build your projects for iOS.\nTo be able to build for iOS and run apps in the native emulator, verify that you have installed xcodeproj.","platforms":["iOS"]},{"warning":"WARNING: CocoaPods is not installed or is not configured properly.","additionalInformation":"You will not be able to build your projects for iOS if they contain plugin with CocoaPod file.\nTo be able to build such projects, verify that you have installed CocoaPods.","platforms":["iOS"]}]},"Android":{"canExecuteLocalBuild":false,"warnings":[{"warning":"The ANDROID_HOME environment variable is not set or it points to a non-existent directory. You will not be able to perform any build-related operations for Android.","additionalInformation":"To be able to perform Android build-related operations, set the `ANDROID_HOME` variable to point to the root of your Android SDK installation directory.","platforms":["Android"]},{"warning":"WARNING: adb from the Android SDK is not installed or is not configured properly. ","additionalInformation":"For Android-related operations, the NativeScript CLI will use a built-in version of adb.\nTo avoid possible issues with the native Android emulator, Genymotion or connected\nAndroid devices, verify that you have installed the latest Android SDK and\nits dependencies as described in http://developer.android.com/sdk/index.html#Requirements","p latforms":["Android"]},{"warning":"WARNING: The Android SDK is not installed or is not configured properly.","additionalInformation":"You will not be able to run your apps in the native emulator. To be able to run apps\nin the native Android emulator, verify that you have installed the latest Android SDK \nand its dependencies as described in http://developer.android.com/sdk/index.html#Requirements","p latforms":["Android"]},{"warning":"Cannot find a compatible Android SDK for compilation. To be able to build for Android, install Android SDK 28 or later.","additionalInformation":"Run `$ sdkmanager` to manage your Android SDK versions.","platforms":["Android"]},{"warning":"You need to have the Android SDK Build-tools installed on your system. You can install any version in the following range: '>=23 <=28'.","additionalInformation":"Run `$ sdkmanager` from your command-line to install required `Android Build Tools`. In case you already have them installed, make sure `ANDROID_HOME` environment variable is set correctly.","platforms":["Android"]}]}}
[…]

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*
+1

Kommentieren

Sie müssen sich einloggen, um sich an einer Diskussion beteiligen zu können.

OK MacTechNews.de verwendet Cookies unter anderem für personalisierte Inhalte, Seitenanalyse und bei der Auslieferung von Google-Anzeigen. Dies war zwar schon immer so, auf Wunsch der EU muss nun jedoch explizit darauf hingewiesen werden. Durch Nutzung der Website erklären Sie sich damit einverstanden. Weitere Informationen