błąd sed: „nieprawidłowe odniesienie \ 1 na prawej stronie komendy` s '”

104

Uruchamiam kilka poleceń zastępowania jako rdzeń skryptu kolorowania dla maven . Jedno z sedpoleceń używa wyrażenia regularnego, które działa w powłoce, jak omówiono tutaj . Aktualną (nie działającą) implementację można znaleźć tutaj .

Kiedy dołączam jeden z wariantów polecenia do skryptu, zachodzi się inaczej:

Wariant 1:

$ sed -re "s/([a-zA-Z0-9./\\ :-]+)/\1/g"

Dostosowane do scenariusza:

-re "s/WARNING: ([a-zA-Z0-9./\\ :-]+)/${warn}WARNING: \1${c_end}/g" \

Błąd: Powłoka wyświetla te same informacje, co gdybym wpisał $ sed. Dziwne!?

Wariant 2:

$ sed -e "s/\([a-zA-Z0-9./\\ :-]\+\)/\1/g"

Dostosowane do scenariusza:

-e "s/WARNING: \([a-zA-Z0-9./\\ :-]\+\)/${warn}WARNING: \1${c_end}/g" \

Błąd:

sed: -e wyrażenie # 7, char 59: niepoprawne odniesienie \ 1 do prawej strony polecenia `s '

regex sed substitution

— JJD
źródło

10

W moim przypadku połączyłem -iopcję (edit in place) z -re, co spowodowało -ire(tak, że -izużywał refragment jako jego SUFFIXargument, a zatem rozszerzony tryb regex nie był włączony); zmieniając go, aby -i -rerozwiązać problem.

— Janaka Bandara

Warto również zauważyć, że apostrofy 'i podwójne cudzysłowy "są traktowane nieco inaczej, szczególnie podczas interpretacji $vars. Na przykład: sudo sh -c "sed -r -i 's/(^.+_supplicant.conf)/\1${MTXT}/' /etc/network/interfaces"działa, ale: sudo sh -c 'sed -r -i "s/(^.+_supplicant.conf)/\1${MTXT}/" /etc/network/interfaces'nie.

— not2qubit

52

Czy nie musisz faktycznie rejestrować, aby to zadziałało? tj. dla wariantu 2:

-r -e "s/WARNING: (\([a-zA-Z0-9./\\ :-]\+\))/${warn}WARNING: \1${c_end}/g" \

(Uwaga: nieprzetestowane)

Bez argumentu -r odniesienia wsteczne (takie jak \ 1) nie będą działać.

— Denis de Bernardy
źródło

42

-rOpcja pojawi sed być konieczne do tylnej odniesieniu do pracy. Np. sed -e 's/([[:digit:]])/is a digit/'Działa, ale sed -e 's/([[:digit:]])/\1 is a digit/generuje oryginalny błąd bez -rseda. UWAGA: pierwsze wywołanie sed wyszukuje literał (<digit>)i nie jest grupą przechwytywania.

— Andrew Falanga

Komentarz pod odpowiedzią jest w rzeczywistości odpowiedzią. Może możesz zmodyfikować swoją odpowiedź, aby ją odzwierciedlić.

— miroxlav

@AndrewFalanga powinieneś był opublikować swój komentarz jako odpowiedź

— sanmai

2

Nieważne, moim błędem było używanie -irezamiast używania -ri. Porządek ma znaczenie :-)

— m3nda

54

Ten błąd występuje często w przypadku nawiasów bez zmiany znaczenia. Ucieknij im i spróbuj ponownie.

Na przykład:

/^$/b
:loop
$!{
N
/\n$/!b loop
}
s/\n(.)/\1/g

Przed każdym nawiasem należy używać odwrotnych ukośników:

/^$/b
:loop
$!{
N
/\n$/!b loop
}
s/\n\(.\)/\1/g

— e18r
źródło

6

Uwaga, jeśli używasz -r, nie musisz uciekać przed nawiasami.

— qräbnö

13

Jeśli opcja -r/ --regexp-extendednie jest podana, należy wprowadzić zmiany w nawiasach przechwytujących.

— OrangeDog
źródło

5

Musisz uciec /po.

sed -e "s/\([a-zA-Z0-9.\/\\ :-]\+\)/\1/g"

Lub jeśli nie chcesz się martwić o ucieczkę, użyj |

sed -e "s|\([a-zA-Z0-9./\\ :-]\+\)|\1|g"

EDYTOWAĆ:

sed -e "s|WARNING: \([a-zA-Z0-9.-/\\ :]+\)|${warn}WARNING: \1${c_end}|g"

— slackmart
źródło

Brzmi rozsądnie. Ale to nie działa w kontekście scenariusza.

— JJD

Przepraszam. Edit podnosi błąd: sed: -e expression #7, char 58: Invalid range end. Odpowiedź @Denisa działa.

— JJD

2

Ok, a potem +1 dla odpowiedzi

— @Denis