znajdź użycie z -L

mam

link -> file

ja robię

find -L . -name 'link'

I dostać

./link

Dlaczego?

człowiek znaleźć mówi:

-L: Śledź linki symboliczne. Gdy find sprawdza lub drukuje informacje o plikach, wykorzystywane informacje należy pobrać z właściwości pliku, do którego prowadzi link, a nie z samego łącza (chyba że jest to zepsute łącze symboliczne lub find nie może zbadać pliku do którego prowadzi link).

find symlink

— Ankur Agarwal
źródło

Odpowiedzi:

Za pomocą -Lsprawdza właściwości pliku - zawartość lub metadane, a nie właściwości łącza. Np. Jeśli użyjesz -atime, sprawdzi atimeplik, a nie link:

$ find testdir/ -name link -newer testdir/ref
testdir/link
$ find -L testdir/ -name link -newer testdir/ref
$

testdir/linkzostał utworzony później testdir/ref, ale plik, na który wskazuje, nie był.

— Kevin
źródło

Czy możesz wyjaśnić, biorąc mój przykład? Rozumiem to: w moim przykładzie find rozpoczyna wyszukiwanie. Napotyka ./link, ponieważ -L powoduje, że deereferencje i przyjmuje właściwości ./file. Porównuje nazwę pliku ./ ze wzorcem „link”, a ponieważ nie pasuje, nie powinien zgłaszać żadnego polecenia. Co jest nie tak z moim rozumowaniem?

— Ankur Agarwal

Z cytowanego podręcznika znajdowania „wykorzystane informacje pochodzą z właściwości pliku, do którego prowadzi link”. Nazwa pliku nie jest jedną z jego właściwości, więc nadal używa nazwy łącza. Jest to również o wiele bardziej przydatne niż nazwa prawdziwego pliku.

— Kevin

„Nazwa pliku nie jest jedną z jego właściwości” Nie wiedziałem o tym. Jakieś inne atrybuty plików, które nie są uważane za właściwości? Szczerze mówiąc nadal jestem sceptyczny i czekam na to, co powiedzą inni.

— Ankur Agarwal

Podobnie jak @abc, nie wiedziałem, że nazwa pliku nie jest właściwością pliku. Gdzie mogę znaleźć tę informację w jakiejkolwiek dokumentacji i / lub stronach podręcznika? Zobacz, gdzie mogę dowiedzieć się więcej o właściwościach pliku.

— joker

Ogólna zasada jest taka, że jeśli polecenie działa na łączach (tj. Pozycjach katalogu, które są wskaźnikami do i-węzłów), wówczas traktuje dowiązania symboliczne jako siebie, a nie jako obiekt, na który wskazuje łącze. W przeciwnym razie polecenie działa na tym, na co wskazuje dowiązanie symboliczne. W ten cpsposób domyślnie podąża za dowiązaniami symbolicznymi i kopiuje zawartość pliku wskazywanego przez dowiązanie. Ale kiedy poprosisz cpo zajęcie się pozycjami katalogu poprzez określenie -R, przestaje on podążać za dowiązaniami symbolicznymi. mvzawsze działa z pozycjami katalogu, więc nigdy nie podąża za dowiązaniami symbolicznymi.

Na findnormalne działanie polecenia jest do pracy w pozycji katalogu, więc dowiązania nie są przestrzegane domyślnie. Dodanie -Lpowoduje findpodążanie za dowiązaniami symbolicznymi dla wszystkich właściwości oprócz tej, której nie można zignorować podczas przeszukiwania katalogu - nazwy. Jednym z celów find -namejest zapewnienie danych wejściowych dla poleceń takich jak mvi rm, które działają na pozycjach katalogu. Byłoby nieprzyjemne i zaskakujące wyniki, gdyby find -L dir -namemożna było wytworzyć nazwy wskazujące poza zakorzenione drzewo katalogów dir.

— Kyle Jones
źródło

ŁAŁ! Dlaczego ta subtelna koncepcja nie jest dobrze zilustrowana na stronach podręcznika (chyba że ją przegapiłem)? To dla mnie wielka niespodzianka.

— Ankur Agarwal,

@Kyle Jones There would be unpleasant and surprising results if znajdź -L nazwa-katalogu` może wygenerować nazwy wskazujące poza drzewo katalogów zakorzenione w katalogu. => Nie powinno tak być: byłoby nieprzyjemne ... gdyby find dir -name pattern...? ponieważ dodanie -L pozwala wskazać na zewnątrz reż

— timotheecour

Jak więc cp -Rskopiować rzeczy pod dowiązaniem symbolicznym?

— javadba