Mac ln -s nie odpowiada, ale wcześniej działał

1

Z góry przepraszam za wszelkie błędy z mojej strony ... Jestem użytkownikiem komputera, który niedawno wrzucił świat Maców dzięki nowej pracy ...

Z systemem OS X Yosemite 10.10.5 PHP wersja 5.5.27 Apache wersja 2.4.16 (Unix)

Próbowałem skonfigurować i uruchomić localhost do lokalnego tworzenia stron internetowych. Zrobiłem to z powodzeniem raz - sam localhost działa bez żadnych problemów.

Problem pojawił się podczas próby utworzenia dowiązania symbolicznego między folderem witryn używanym przez localhost a miejscem, w którym pliki witryn są faktycznie przechowywane (tej lokalizacji nie można zmienić).
(Jestem również świadomy złej praktyki ze spacjami w nazwach plików, ale te strony są już utworzone)

Postępowałem zgodnie z instrukcjami zawartymi w tym samouczku, na początku bez żadnych problemów. http://ole.michelsen.dk/blog/setup-local-web-server-apache-php-osx-yosemite.html

Mam skonfigurowaną JEDNĄ witrynę i pracuję z dowiązaniem symbolicznym utworzonym za pomocą ln -s '~ / Dropbox / Shared Sites / SITENAME ~ / Sites / SITENAME' Nie ma tu żadnych problemów (SITENAME to katalog, w którym znajdują się pliki witryn)

Jednak próbuję teraz dodać drugą stronę. Za pomocą powyższego polecenia terminal przestaje odpowiadać. Do następnego wiersza dodano>, ale wygląda na to, że nie są wykonywane żadne polecenia (dowiązanie symboliczne nie działa). Mogę pisać, ale nie są wykonywane żadne polecenia. Naciśnięcie CTRL + C przywraca terminal do poprzedniego stanu, w którym ponownie przyjmie polecenia. Wszystkie pozostałe polecenia wydają się działać poprawnie.

Sprawdziłem, czy katalog istnieje, i mogę do niego wykonać cd. Próbowałem także uruchomić ln -s '/ SITENAME ~ / Sites / SITENAME' w folderze nadrzędnym, z tym samym rezultatem. Próbowałem także uruchomić polecenie z sudo

Próbowałem również pobrać i używać iTerm, z tym samym rezultatem.

Próbowałem również utworzyć dowiązanie symboliczne dla trzeciej / oddzielnej strony, to samo ponownie.

Czy ktoś może rzucić jakieś światło na to, dlaczego to polecenie przestało działać podczas poprzedniej pracy oraz jak to naprawić lub obejść, aby dodać dodatkowe witryny do hosta lokalnego?

Dzięki :)

Roxy Walsh
źródło
Myślę, że używasz apostrofów tam, gdzie nie są one wymagane, nie są pomocne i faktycznie są szkodliwe. Spróbuj biegać bez tych apostrofów.
TOOGAM,
@TOOGAM - Wspaniale, dziękuję - dziwnie, wcześniej działało z apostrofami - nie działa tylko z usuniętymi apostrofami (ze względu na spacje w nazwach plików ...) - ale właśnie próbowałem uciec spacjom za pomocą \ i wydaje się, że teraz działa! Więc użyłem ln -s ~ / Dropbox / Shared \ Sites / SITENAME ~ / Sites / SITENAME (na wypadek, gdyby ktokolwiek spotkał się z tym w przyszłości)
Roxy Walsh

Odpowiedzi:

0

Dla jasności dla każdego, kto może mieć ten sam problem (nie mogę być jedynym, prawda?: S):

Dzięki @TOOGAM - rozwiązaniem było usunięcie apostrofów / cudzysłowów, a zamiast tego , unikanie spacji za pomocą \ - więc polecenie, które teraz działa, jest

ln -s ~ / Dropbox / Shared \ Sites / SITENAME ~ / Sites / SITENAME

Nadal nie jest mądrzejszy, dlaczego pierwotnie działał z apostrofami, ale problem został rozwiązany mimo wszystko! :)

Roxy Walsh
źródło
0

Wszystkim innym, którzy się przyłączą, zobacz także odpowiedź Roxy Walsh, która zawiera dodatkowe informacje na temat problemu, które są potrzebne, aby zrozumieć niektóre szczegóły podane w mojej odpowiedzi.

Dobra, oto umowa:
apostrofy uciekały przed tyldami.

Spróbuj tego:

echo ~
echo '~'

Przekonasz się, że pierwsze polecenie rozszerza ~ do twojego katalogu domowego. W drugim poleceniu otrzymasz prawdziwą tyldę. Tylda „uciekła”. Ucieczka oznacza określenie, że postać musi być traktowana jak normalna postać, zamiast mieć specjalne znaczenie.

Teraz musisz uciec z przestrzeni, co zrobiłeś z odwrotnymi ukośnikami, ale nie uciec przed tyldą. Spacje mają zwykle specjalne znaczenie, które mają na celu oddzielenie parametrów. Nie chcesz tego oddzielać: twoje miejsce w „Shared Sites /” jest częścią jednego katalogu. Ta konkretna przestrzeń nie ma na celu poinformować polecenia „ln”, że skończyłeś określać pierwszy plik / katalog, a masz zamiar podać następny plik / katalog. Więc trzeba było uciec z tego miejsca.

W oparciu o pokazany przykład działałyby również:

ln -s ~ / 'Dropbox / Shared Sites / SITENAME' ~ / Sites / SITENAME

TOOGAM
źródło
To ma sens, dziękuję za szczegółowe wyjaśnienie! :)
Roxy Walsh