Bash WTF!!!

Egy videót akarok átkonvertálni mencoder-rel. A probléma csak az, hogy a fájlnévben felkiáltójel van. Úgyhogy ezt kapom:


bash: !,: event not found

Rákerestem az üzenetre, és azt írták valahol, hogy escape-eljem, akkor meg a fájlnév részének tekinti a backslash-t is, és mencoder ír hibát (nem találja a fájlt).

Ha valaki ajánlana egy olyan shell-t Linux-ra, ami nem egy 20+ éves vacak, azt megköszönném!

( zidane2005 | 2010. 08. 03., k – 00:16 )

Esetleg ilyesmi: mcedit filenev'!'masodikresze.txt

( BaT | 2010. 08. 03., k – 00:31 )

Próbáld úgy, hogy a felkiáltójelet és a vesszőt is escapeled. Bár elég csak a felkiáltójelet. 


user@host:~/sandbox$ uname -a
Linux host 2.6.18-6-686 #1 SMP Thu Aug 20 21:56:59 UTC 2009 i686 GNU/Linux
user@host:~/sandbox$ echo $SHELL
/bin/bash
user@host:~/sandbox$ bash --version
GNU bash, version 3.1.17(1)-release (i486-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
user@host:~/sandbox$ cat > \!, << EOF
> Valami szoveg,
> hogy lasd, nem
> ures a file.
> EOF
user@host:~/sandbox$ ls
!,
user@host:~/sandbox$ cat \!,
Valami szoveg,
hogy lasd, nem
ures a file.
user@host:~/sandbox$

Egyébként meg használj tab-completiont, és akkor az szépen kiescapeli magának.
--
Don't be an Ubuntard!

( gd | 2010. 08. 03., k – 00:23 )

Szimpla idézőjelbe téve nem tekinti eseménynek, és idézőjel nélkül egy backslash-t elé téve sem - ekkor \ nélkül adja át a programnak. Dupla idézőjeles stringben tehát "\!"

"Ha valaki ajánlana egy olyan shell-t Linux-ra, ami nem egy 20+ éves vacak, azt megköszönném!"

Ez azért kicsit erős volt a szinte biztos pebkac mellett.

Ez azért kicsit erős volt a szinte biztos pebkac mellett.
Pláne, hogy hasonló escape-elési finomságok bizony még a powershellnél is vannak (sőt elvileg sem kerülhetőek el), pedig arra aztán nem fogható rá, hogy egy 70-es évekből szökött shell volna.
---
Internet Memetikai Tanszék

Lehet ezt pebkac-nak nevezni, gondolom ha mélyebben beleástam volna magam a dologba, akkor megtaláltam volna a megoldást. De ez nem változtat azon, hogy a bash szerintem nagyon hülyén és abszolút nem logikusan kezeli a dolgot. Vagy szerinted nem az lenne a logikus hogy a programnak már a feldolgozott stringet küldi tovább?

( saabi v | 2010. 08. 03., k – 07:18 )

Nevezd át x-nek és felejtsd el a speciális karaktereket a file-ok nevében!

Ave, Saabi.

+1

Egyszerűen gyűlölöm, ha valaki mondatot ad meg fájlnévnek. Főleg, ha tele van öüóőúűáéí betűkkel. Hiába kezeli a Linux is, Windows is, OS X stb. ezeket a karaktereket, akkor is sokat szívtam már emiatt, leginkább a tömörített állományoknál. Fájlnévbe személy szerint csak az angol ABC betűit teszem. Próbálok mindenkit rászoktatni erre a környezetemben, mert már elegem van abból is, hogy folyton mennem kell segíteni, mert az iwiw, facebook, stb. nem tudja képfeltöltéskor rendesen kezelni az ilyen magyaros fájlneveket.

SKL - leírásgyűjtemény és informatikai portál

De ez akkor is vicc. Miért nem képes kapásból átkonvertálni? 2010-et írunk...
(Na nem mintha 5 évvel ez előtt már nem lett volna ideje az ilyesminek.)

(DE! Még jó hogy van jópár alternatíva. Kicsit ironikusnak tartom hogy a legtöbb alternatívát melyet felsorolnak mellette végülis PowerShell koppintás mikor az "béna" a sok binyugz profinak.)

Nem konverziós hiba. RTFM!
Van egy olyan fogalom, hogy "reserved words", ami azokat a szavakat, jeleket jelenti, amelyek kerülendőek mivel speciális jelentéssel bírnak. Ilyen a "!" is, de épp ezért nem teszünk "|"-t sem filenévbe és nem kezdjük azt "-"-zel.
Arról, hogy te nem tudsz valamit használni és lusta vagy elolvasni a leírását, még nem az a valami tehet!

Ave, Saabi.

Linux? 


saabi@loft1809:~/test$ ls -l
total 0
-rw-r--r-- 1 saabi saabi 0 Aug  3 10:26 felkialto!jel.txt
-rw-r--r-- 1 saabi saabi 0 Aug  3 10:26 idezo"jel.txt
saabi@loft1809:~/test$ uname -a
Linux loft1809.serverloft.com 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux

Ave, Saabi.


[hron@sunshine ~/Downloads/sandbox ] $ ls -l
total 16
-rw-r--r--  1 hron  staff  1 Aug  3 11:50 Felkialtojel!
-rw-r--r--  1 hron  staff  1 Aug  3 11:50 Idezo"jel

Apple Mac OS X 10.5.8

De gyanitom, hogy minden modern oprendszer enged ilyen allatsagokat csinalni - eppencsak nem illik.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.


saabi@loft1809:~/test$ ls
felkialto!jel.txt  idezo"jel.txt
saabi@loft1809:~/test$ rm felkialto\!jel.txt
saabi@loft1809:~/test$ rm idezo\"jel.txt
saabi@loft1809:~/test$ ls -l
total 0
saabi@loft1809:~/test$

Windows Vista már akkor szól, hogy többek közt idézőjel sem lehet a file nevében, amikor létre akarom hozni azt.

Ave, Saabi.

Ha a belsejében van, miért ne mehetne? Elkezdi első zárójeltől, amíg nem végez, az mind a fájlnév, és utolsó "-nél végez.

(Nem idézejltől idézőjelig megy)

(De hülyeség is EZT ecsetelni , mivel tomaza-nak igaza van, normális rendszer alapból nem enged olyan fájlnevet adni.)

Te akartál AKÁRMILYEN file nevet. De ha az időzejelet mégis kihagyhatjuk az engedélyezett karakterek közül, akkor egyéb vezérlő karaktereket miért ne?
Mindegy is, ez az egész csak szócséplés. A felkiáltójel a bashnál vezérlőkarakter s mint ilyen, eltakarandó. Ha pedig a mencoder a backslash-el történő takarásnál a backslasht is a file név részének tekinti... jó kérdés, hogy a backslasht a file nevéből kiveszi-e a shell, amikor azt paraméterként átadja a programnak, vagy a programnak kell értelmeznie és elvetnie? Ezt mondjuk nem tudom. De nehezen hiszem, hogy a bash hibája volna, ha a mencoder nem érti a backslashel kitakart karaktert tartalmazó file nevet.

Ave, Saabi.

Unixon minden helyettesítést, escape-elést stb. a shell végez. a program a kész fájlnevet kapja meg. (Ennek megfelelően ha \-t kap, akkor úgy kell tekintenie, hogy a fájlnév része, mert ha az ember escape-eli a \-t, akkor az a shellnek szól, így a program már csak egy \-t kap.)

A probléma abból adódott, hogy dupla idézőjelek között a bash feldolgozza a nem escape-elt !-t,ha pedig \-t rak elé az ember, akkor (a $, `, \ escape-elésével ellentétben) a \ is megmarad (dupla idézőjelek között a \ csak akkor nem marad meg, ha az előbbi három valamelyike előtt áll). Viszont ez egyszerűen megoldható, ha idézőjekek nélkül írunk \!-t, vagy szimpla idézőjelekbe (ez a legegyszerűbb, ott a ' kivételével semmi nem speciális) !-t.

Speciel ragozhatod ahogy akarod, de az a gáz, hogy nem ismered, hogy a shell(ek) hogy működnek, ismersz belőle egy-két dolgot - de nem az egészet -, és ha nem tudod jól használni, akkor minden(ki) másban van a hiba.

Ha valamit 'aposztrófok' közé teszel, ott nem lesz semmiféle speciális karakter értelmezés. Ez alól a bash kivétel(egyébként a csh-ból lopva az ötletet) : még aposztrófok között is speciálisnak tekinti a felkiáltójelet. Ha tehát azt nem akarod, hogy a shell annak tekintse, azt kénytelen vagy az erre egyedül szolgáló backslash segítségével eltakarni.

Ez minden UNIX-like rendszereben így van, legfeljebb ha nem bash-t, hanem valami normálisabb shell-t használsz, akkor ezzel a kivétel-kivételének-a-kivétele esettel nem kell foglalkoznod.

(Végül egy megjegyzés: "ez az" idézőjeles" módszer" ami itt fentebb, mint lehetséges felvetés előkerült, ezzel van két gond:

- nem így találták ki, tehát vagy írsz saját parancsértelmezőt ami így működik, és te azt használod, vagy hozzászoksz a gondolathoz, hogy nem így megy;

- a másik gond, hogy mit kezdesz a sorban szereplő egy darab idézőjellel? Vagy mi van, ha be szeretnék tenni egy idézőjel-enter-kombót? Vagy - szóval lehet néhány eléggé nyakatekert ellenpéldát találni, ami a jelenlegi - létező, működő megoldással mind-mind megadható, ellenben ezzel a kezdő- és zárózárójel trükkel rohadtul nem. Márpedig a szabály az, hogy minden szar lehet egy fájl nevében, a / és a '\0' karakterek kivételével. És ezt az elterjedten használt shellek segítségével be is tudod gépelni - ha megtanulod használni.

http://opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_…

posix ieee 1003.1-2008
lehet, hogy a filerendszer elviseli, de az oprendszer semmiképpen nem ajánlja. már amennyiben posix-szerű. ennek a korlátnak figyelembe vételével tudnánk egyszerűen együttműködni különféle rendszerek (OS,FS,CHARSET) használata mellett. interoperabilitás.
az ajánlás/szabvány ismerete és használata helyett inkább anyázzuk le a megvalósítást?

az a logikus, hogy balról jobbra elemez amíg nem kell vermelnie. de lehetne inverz-lengyel is, csak akkor az nem tetszene ;)

Napi használatban az URL böngészőnek szól (következésképpen nem igazán kéne a shell-nek belepofáznia). Aki meg van olyan májer, hogy parancssori eszközökkel operál (youtube-downloader meg wget és társai), az tanulja meg a parancssori eszközöket az őáltala használt rendszeren. Szerintem ez ilyen egyszerű.

ha az a file mime-vel jön, akkor a szervertől kap filename mezőt amiben lehet normális filenév. ha a saveas a kedvenc letöltési módunk, akkor az "as" miatt megadhatunk a kliens oldalon ábrázolható nevet.
de nem sokkal egyszerűbb lenne, ha már az elején gondolnánk minderre és a szabványok lehetőségein belül maradnánk? azaz aki a filét legyártotta az posix neveket használna?

Öreg, veled kommunikálni olyan mint sajtreszelővel rejszolni. Másnak felhánytorgatod a nem létező szövegértési problémáit, ugyanakkor fogalmazni meg nem tudsz. Közlöd, hogy a Mac OS nem UNIX, csak a parancssora és meglepődsz ha erre a baromságra az értelmesek felhorkannak. Utána ahelyett hogy csendben maradnál még baszogatsz, hogy válaszoljak a hülyeségeidre.
Nos, ez az utolsó válaszom, hagyj békén és fárassz mást!

Ave, Saabi.

rfc3986
mivel a ! karakter határoló-karakter - tehát mégis speciális -, ezért nem javasolt a használata a uri/path tagban; ha mégis ilyen indíttatásunk lenne, akkor urlencodinggal kell védeni. és tudomásul venni, hogy másoknak gondot okozhat a reprezentáció, azaz szívni fog vele valaki.

az en kedvencem az, amikor user nem tud torolni (ftp-n) egy konyvtarat. Miert? Mert rejtett file van benne. Amikor nyivakol, hogy toroljem le, akkor az a default valasz az arcaba, "de hat ha fel tudtad tenni, akkor le is tudod torolni (allitsd csak be rendesen a **king ftp kliensedet....)".

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Ez nem mindig jatszik, pl webtarhelynel van, hogy a webapp hoz letre .htaccess fajlokat, amit a user keptelen letorolni, mert a normalisan konfiguralt FTP szerverek minden ponttal kezdodo fajlnevet blokkolnak, barmilyen parancsban alljon is.
Szoval igen, eloallhat olyan eset, hogy nem tud letorolni egy mappat, mert rejtett fajl van benne.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

És hol itt a probléma? Ha többféle shellt használsz, akkor tanuld meg őket. Ha nem tudod megtanulni, minek használsz többfélét? Az emberek a saját rendszerükben tudnak shellt választani, ha esetleg egy másik rendszerben nem is. Én pl. munkámból kifolyólag leginkább Korn-shellt használok, és a saját rendszreimben is egy ahhoz (a bashnál) sokkal jobban hasonlító shellt választottam.

A subject-ben bash szerepel, ez a topic arról szól. Felesleges ettől eltérni. A témához kapcsolódó megjegyzésem pedig: az, hogy a bash tele lenne értelmetlen korlátokkal, szerintem túlzás, simán dolgozik a bash unicode filenevekkel, max. a terminál nem jeleníti meg pl a kanjikat, ha nincs jól belőve :-D szóval ha megnézzük, hogy mit használhatunk, és mit nem, azt hiszem kihagyható az a néhány karakter, nem csorbultak a file elnevezési lehetőségeink jelentősen... :-D

Nem felesleges a bashtol elterni. Ugyanis az egy dolog, hogy bash alatt akarja kezelni, modositani az ember a fileokat, de nem biztos, hogy bash segitsegevel keszultek ezek a fileok, igy lehet bennuk a bash szamara specialis karakter, hiszen ezek a karakterek a keszites soran nem feltetlenul birtak specialis jelentessel.

( zamboriz v | 2010. 08. 03., k – 08:45 )


$ ls a!a
bash: !a: event not found

$ set +H
$ ls a!a
ls: a!a nem érhető el: Nincs ilyen fájl vagy könyvtár

( agolon | 2010. 08. 03., k – 09:21 )

> bash: !,: event not found
> Rákerestem az üzenetre

Legalább tanultál volna valami hasznosat belőle. :)
--
2e845cb4c3a5b5bd6508455b1739a8a2

( T_chris | 2010. 08. 03., k – 21:34 )

Csak átszaladtam a topicot.
/home/neved/file!.kiterjesztés
helyett
/home/neved/file*.kiterjesztés
formát használd.
- - - - - - - - - - - - - - - - - - - - - - - - -
Fejlődőképes hiperláma, és okleveles érdekfeszítő