Nie możesz użyć wykrzyknika (!) W bash?

86

Próbuję użyć polecenia curl, aby uzyskać dostęp do adresu URL z wykrzyknikiem ( !) na ścieżce. na przykład:

curl -v "http://example.org/!287s87asdjh2/somepath/someresource"

konsola z odpowiedzi bash: ... event not found.

Co tu się dzieje? i jaka byłaby właściwa składnia, aby uniknąć wykrzyknika?

bash quoting special-characters

— sieć mózgu
źródło

Rozwiązany w bash 4.4+

— Izaak

98

Wykrzyknik jest częścią ekspansji historii w bash. Aby go użyć, musisz go ująć w pojedyncze cudzysłowy (np .:) 'http://example.org/!132'lub bezpośrednio uciec ukośnikiem odwrotnym ( \) przed znakiem (np "http://example.org/\!132".:).

Zauważ, że w podwójnych cudzysłowach odwrotny ukośnik przed wykrzyknikiem zapobiega rozszerzeniu historii, ALE odwrotny ukośnik nie jest usuwany w takim przypadku. Lepiej więc używać pojedynczych cudzysłowów, aby nie podawać dosłownego odwrotnego ukośnika curljako części adresu URL.

— Daniel Pittman
źródło

8

"http://example.org/\!132"faktycznie rozwija się bez interpretacji ukośnika odwrotnego (uważam, że jest to zgodne z POSIX).

— Chris Down,

@ChrisDown, próbowałem wyjaśnić, że to moja druga opcja w tekście. Dziękujemy za zwrócenie uwagi na potencjalne zamieszanie.

— Daniel Pittman,

6

Dla przypomnienia: próba ucieczki przed „!” Nie jest przenośna. Najlepszą praktyką jest, aby zawsze cytować (pojedyncze cytaty) „!”. Powiązane: „^” (karetka), to metaznak, który wymaga cytowania w celu przenoszenia. Wreszcie, "!" nie powinien być stosowany w instrukcji if; użyj go jako argumentu do testowania, jeśli to możliwe (ponownie z powodu Solaris / bin / sh).

— Nicholas Wilson

5

Pracowały dla mnie tylko pojedyncze cytaty. zsh wciąż tłumaczył \!i podwójnie cytował.

— orkoden

1

W systemie Solaris (stara śmieci przed wersją XPG4) „^” jest aliasem |i służy do tworzenia potoku. Jeśli wysyłasz skrypty do klientów i nie masz pewności, w jakiej powłoce będą one uruchamiane, musisz przetestować je wszystkie!

— Nicholas Wilson

61

Oprócz odpowiedzi udzielonej przez Daniela możesz także po prostu całkowicie wyłączyć rozszerzanie historii, jeśli jej nie używasz set +H.

— Chris Down
źródło

19

Całkowite wyłączenie ekspansji historii to najlepsza rada, jaką słyszałem przez cały dzień! Ekspansja historii jest niebezpieczna i bizantyjska, gdy istnieją o wiele lepsze alternatywy (przyrostowe przeszukiwanie historii za pomocą Ctrl-R), które umożliwiają podgląd i edycję polecenia, abyś nie ślepo strzelał z poleceniem, !-14które ci się !-12wydawało, ups rm -rf *. Bądź bezpieczny. Wyłącz rozszerzanie historii! Unikaj !!

— aculich

6

Największa odpowiedź: ekspansja historii stanowi ogromne zagrożenie bezpieczeństwa! Można go użyć do zaatakowania Uniksa poprzez spreparowany adres URL.

— dan

@ aculich lub po prostu użyj zamiast tego polecenia podanegofc -14 przez POSIX . Ale to prawda, że możesz to zrobić bez włączonego rozszerzenia historii. Osobiście używam !$i !via sudo !!, a nawet git add !vi:$dość często, aby uzasadnić pozostawiając włączony ekspansja historia.

— Wildcard

Myślę, że dodam to do moich plików RC powłoki. Użyłem tego tylko jako zgrabnego „

— trika

17

Osobiście robiłbym pojedyncze cytaty, ale dla kompletności, również zauważę, ponieważ jest to adres URL, możesz zakodować !jako %21np curl -v http://example.org/%21132.

— Aaron D. Marasco
źródło

13

To też może zrobić

curl -v "http://example.org/"'!'"287s87asdjh2/somepath/someresource"
lub
curl -v "http://example.org/"\!"287s87asdjh2/somepath/someresource"

Co działa, ponieważ bash łączy sąsiednie łańcuchy. To podejście jest szczególnie przydatne, gdy masz inne rzeczy, które wymagają rozszerzenia powłoki, więc nie możesz używać pojedynczych cudzysłowów dla całego łańcucha:

curl -v 'http://example.org/!'"287s87asdjh2/${basepath}/someresource"

!znak służy do rozszerzania historii w wierszu polecenia.
może to być problemem w pytaniu, ale nie w plikach skryptów powłoki.
jak widać rozszerzenia historii działają nawet w podwójnych cudzysłowach.

— mug896
źródło

Istnieje wiele sposobów na to, aby polecenia uniksowe i angielskie zdania używały więcej znaków, niż powinny, i były bardziej mylące, niż powinny. W jaki sposób przewyższa to pierwszą / zaakceptowaną / najwyżej głosowaną odpowiedź, a mianowicie umieszczenie całego adresu URL w pojedynczym cudzysłowie?

— G-Man,

2

@ G-Man: Podaje inny sposób konstruowania argumentów bash. Nie wiedziałem o tej metodzie. Nic złego w uczeniu się nowych rzeczy.

— Sahil Singh,

@SahilSingh Jak to jest nowe? Łączy trzy ciągi, dwa ujęte w podwójne cudzysłowy i jedno ujęte w pojedyncze cudzysłowy. Tutaj nie ma gniazdowania.

— Raphael,

@ G-Man Nie jest oczywiste, że po umieszczeniu 2 łańcuchów obok siebie łączą się one. printf („cześć” „świat”) również działałby w c, ale printf („cześć” „w”) nie będzie działać, więc widzisz, że bash dostosowuje takie wyrażenia był dla mnie nowy, ale zgadzam się z z punktu widzenia użyteczności, to nie jest lepsze. Podobała mi się odpowiedź, podobnie jak Mark Shust.

— Sahil Singh,

2

@ G-Man Przydaje się również, gdy istnieją inne rozwinięcia ciągów , które chcą się odbywać w tym samym ciągu. Jest to łatwy sposób na rozdzielenie dwóch rodzajów zachowań związanych z cytowaniem.

— WAF

7

Natknąłem się na ten sam problem, a moim prostym rozwiązaniem było użycie zmiennej:

E=!  
curl -v "http://example.org/${E}287s87asdjh2/somepath/someresource"

Tutaj prostota polega na tym, że (1) jest przenośny między powłokami i poleceniami (2) Nie wymaga znajomości składni Escape i kodów ASCII.

— Prem
źródło

3

Od czasu wersji Bash 4.3 możesz teraz używać podwójnych cudzysłowów, aby zacytować znak rozszerzenia historii:

$ bash --version
GNU bash, version 4.3...
[...]
$ echo "Hello World!"
Hello World!

— Flimm
źródło

to nie działa poza echo, echo wydaje się radzić sobie z tym inaczej

— phil294

@Blauhirn To nie ma nic wspólnego z echem, a wszystko z cytatem i wersją bash, którą uruchamiasz.

— Flimm

2

Ta odpowiedź jest błędna i powinna zostać usunięta. Twoja bashwersja nie ma nic wspólnego z tym, że huk nie jest rozszerzany, wynika to z faktu, że w twoim przykładzie !następuje „koniec linii”, co uniemożliwia powłoce próbę jej rozwinięcia. Spróbuj, echo "!Hello World"a zobaczysz, że bashodpowie bash: !Hello: event not found. Więcej informacji na ten temat można znaleźć w instrukcji obsługi

— don_crissti,

0

Dla tych, którzy używają git bash w Windows, działa odpowiedź zaakceptowana przez @DanielPittman. Powinieneś jednak zastąpić ukośnik odwrotny (\) ukośnikiem (/).

Na przykład w Uniksie wyglądałby mniej więcej tak:

curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS\!ZR412543s'

W przypadku systemu Windows byłoby to mniej więcej tak (skoncentruj się na ukośniku w części nagłówka autoryzacji)

curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS/!ZR412543s'

— SamuelDev
źródło

To nie ma większego sensu. Podano pojedynczy argument, więc niezależnie od ukośników, wykrzyknik nie spowoduje rozszerzenia historii.

— Wildcard

Och, masz rację. Wysłałem tylko tę odpowiedź, ponieważ kiedy korzystałem z odpowiedzi Daniela (używając odwrotnego ukośnika), pojawia się błąd.

— SamuelDev,