Jak naprawić błąd „niepoprawny identyfikator” po ustawieniu zmiennych środowiskowych?

Próbuję skonfigurować cocos2dx w Ubuntu 14.04 LTS, ale po ustawieniu zmiennych środowiskowych (in .bashrc) zaczynam otrzymywać ten błąd:

bash: export: dev/cocos2d-x-3.2/tools/cocos2d-console/bin': not a valid identifier 
bash: export:/home/john/android': not a valid identifier 
bash: export: dev/android-ndk-r10b': not a valid identifier 
bash: export:dev/adt-bundle-linux-x86_64-20140702/sdk': not a valid identifier

I nie wiem, co zrobić, aby to naprawić.

ale po ustawieniu zmiennych środowiskowych

Wygląda na to, że nie zrobiłeś tego poprawnie.

Otrzymywane błędy oznaczają, że ścieżki (jak /home/john/android) są używane jako nazwy zmiennych, a nie jako przypisane im wartości .

• Prawidłowa składnia do przypisania zmiennej to NAME=value.
• Prawidłowa składnia do eksportowania zmiennej (o dowolnej wartości, jeśli taka istnieje, została już przypisana) export NAME.
• Prawidłowa składnia do przypisania i eksportu zmiennej (z przypisaną wartością) w tym samym czasie to export NAME=value.

Podejrzewam, że próbujesz zrobić trzecią rzecz, ale używasz złej składni. Pięć typowych błędów, które mogą powodować błędy takie jak to, co widzisz:

1. Używanie spacji zamiast =. export NAME valuejest nieprawidłowe; valuejest następnie interpretowane jako nazwa kolejnej zmiennej do wyeksportowania.

   (Dzieje się tak, ponieważ export NAME1 NAME2 jest poprawna składnia do eksportowania wielu zmiennych).

2. Rozmieszczanie przestrzeni =. W wielu językach programowania jest to zarówno poprawne, jak i preferowane stylistycznie, aby wstawiać operatorów ze spacjami przez większość czasu. Ale aby przypisać wartość do zmiennej w skrypcie powłoki (lub w innej sytuacji, w której wydajesz polecenia powłoki), jest to niedozwolone. NAME = value(w exportpoleceniu lub w inny sposób) nie będzie działać; musisz użyć NAME=value.

   ( export NAME = valuepróbuje wyeksportować zmienne o nazwach NAME, =i value. Na szczęście nigdy nie wydaje się, że się to udaje po cichu, ponieważ próba wyeksportowania zmiennej o nazwie =jest błędem składniowym. W przeciwieństwie do export NAME= valuetego wydaje się działać, ale nie przypisuje valuedo - NAMEzamiast tego przypisuje puste, łańcuch o zerowej długości NAMEi eksportuje go, a osobno eksportuje zmienną value. Oba są częstymi błędami).

3. Oddzielanie części wartości zmiennej spacjami. Zmienne środowiskowe mogą zawierać spacje, ale w praktyce rzadko są używane jako separatory pól w zmiennych środowiskowych. Gdy pojedyncza zmienna celowo zawiera wiele ścieżek, zwykle :służy do ich rozdzielenia.

4. Brak cytowania spacji podczas przypisywania do zmiennych. Czasami wartość zmiennej środowiskowej powinna zawierać spację. Na przykład może to być nazwa katalogu, który naprawdę zawiera spację. W takim przypadku należy podać dowolne spacje.

   Jednym ze sposobów na to jest ich poprzedzenie \. Zobacz Jak mogę chronić nawiasy przekazywane do polecenia cd? i Nie można usunąć pliku w celu uzyskania informacji o innych sposobach - zastosowanie mają metody przedstawione w odpowiedziach, nawet jeśli żadne pytanie nie dotyczy przypisania zmiennych środowiskowych.

   Na przykład oto kilka sposobów eksportowania zmiennej środowiskowej SILLYPATHo wartości /home/ek/silly name/bin:

   export SILLYPATH=/home/ek/silly\ name/bin

   export SILLYPATH='/home/ek/silly name/bin'

   export SILLYPATH="/home/ek/silly name/bin"

   Często gdy folder, którego musisz użyć w powłoce lub przypisać do powszechnie używanej zmiennej środowiskowej, zawiera spację, zmiana nazwy może być korzystna. (Ale czasem jest to niepraktyczne lub niepożądane).

5. Przypisywanie i / lub eksportowanie zmiennej, gdy nic nie trzeba było robić. To rodzaj meta-błędu; konkretny problem techniczny jest często jednym z powyższych, ale rozwiązaniem jest pozbyć się linii przestępczej lub jej części, zamiast ją naprawić. .bashrcOczywiście nie usuwaj bezkrytycznie kodu . Ale exportmoże zostać dodany przypadkowo lub może przypadkowo mieć w nim więcej kodu, niż zamierzano. Załóżmy na przykład, że chciałeś napisać:

   echo 'export PATH=~/some.bin:"$PATH"' >>~/.bashrc; . ~/.bashrc

   To by się dołączyło .bashrc, a następnie ponownie go źródło. Załóżmy jednak, że zamiast tego napisałeś:

   echo 'export PATH=~/some.bin:"$PATH" . ~/.bashrc' >>~/.bashrc  # WRONG!

   Wtedy twoje exportpolecenie nie tylko wyeksportuje zwiększoną wartość PATH, ale również spróbuje wyeksportować zmienne o nazwach .i , co nie jest tym, czego chcesz. Ponieważ zawierają znaki, które są zabronione w nazwach zmiennych, więc przy każdym uruchomieniu nowej interaktywnej powłoki bash otrzymasz błąd./home/your-username/.bashrc

   Aby uniknąć tego problemu, sugeruję edytowanie .bashrcw edytorze (np. nano ~/.bashrc, gedit ~/.bashrc) Zamiast przekierowywania wyjścia na jego koniec za pomocą >>.

_{Podejrzewam, że może to być wystarczająca informacja, aby znaleźć i naprawić błąd w .bashrcpliku. Jeśli potrzebujesz dalszej pomocy, powinieneś oczywiście opublikować pełną zawartość tego pliku do analizy. (Tylko przez przypadek twój problem był wystarczająco często spotykany i z wystarczająco przejrzystym komunikatem o błędzie, aby umożliwić taką ogólną odpowiedź).}

Upewnij się, że działasz:

export ENV_VARIABLE

Zamiast:

export $ENV_VARIABLE

W przeciwnym razie próbujesz wyeksportować wartość zmiennej, a nie samą zmienną, więc pojawi się ten błąd.

Wyeliminuj spacje i znak dolara. Na przykład działa to tak samo, jak można ustawić moduł ustawień django na serwerze WWW za pośrednictwem SSH, tj .:

export DJANGO_SETTINGS_MODULE=myapp.settings

Widziałem to dość często, gdy kopiujesz coś za pomocą odwróconych przecinków (z Internetu) i aktualizujesz środowisko lub plik bashrc.

Dobrym początkiem byłoby po prostu ręczne wpisanie odwróconych przecinków w wklejonej treści.