Baixe Shell comand doc de exemplos e outras Manuais, Projetos, Pesquisas em PDF para Sistemas Distribuídos, somente na Docsity!
\
Aqui temos um livro livre e completo sobre Shell
Os sedentos do "saber livre" são muito benvindos.
● [ 01 Apr 2008 - 19:01 ] Links Amigos ● BR-Linux ● Viva o Linux ● Dicas-L ● Aurelio ● Thobias
- TWIKI BÁSICO o Página Inicial o Últimas Alterações o Índice o Procura o Estatísticas de Uso o Aviso de Atualização o Mapa do Site
- TWIKI AVANÇADO o Registre-se o Configurações Gerais o Quem Somos o Regras de Formatação o Biblioteca Gráfica o Carinhas Gráficas
- PROJETO GRÁFICO o Pré Tópico o Pós Tópico o Menu Lateral o Menu de Navegação o CSS Utilizado o Botões Especiais o Indica Onde Estamos o Cabeçalho Padrão o Copy Right/Left Você está aqui: TWikiBar > BatePapos > TWikiBarPapo Controles: - Última Atualização: [15 Jan 2008 - V.36]
Papo de Botequim - Parte I
● Diálogo entreouvido entre um Linuxer e em empurrador de mouse: ● O Ambiente Linux ● O Ambiente Shell o Uma Rapidinha nos Principais Sabores de Shell ▪ Bourne Shell (sh) ▪ Korn Shell (ksh) ▪ Boune Again Shell (bash) ▪ C Shell (csh) o Explicando o funcionamento do Shell ▪ Exame da Linha de Comandos ▪ Atribuição ▪ Comando ▪ Resolução de Redirecionamentos ▪ Substituição de Variáveis ▪ Substituição de Meta Caracteres ▪ Passa Linha de Comando para o kernel o Decifrando a Pedra da Roseta ▪ Caracteres para remoção do significado ▪ Apóstrofo ou plic (') ▪ Contrabarra ou Barra Invertida () ▪ Aspas (") ▪ Caracteres de redirecionamento ▪ Redirecionamento da Saída Padrão ▪ Redirecionamento da Saída de Erro Padrão ▪ Redirecionamento da Entrada Padrão ▪ Here Document ▪ Redirecionamento de Comandos ▪ Caracteres de Ambiente
Diálogo entreouvido entre um Linuxer e em
empurrador de mouse:
um arquivo chamado /etc/passwd que além fornecer dados para esta função de "leão-de-chácara" do Linux , também provê informações para o login daqueles que passaram por esta primeira barreira. O último campo de seus registros informa ao sistema qual Shell a pessoa vai receber ao se "logar" (ARGH!!!). Quando eu disse que o último campo do /etc/passwd informa ao sistema qual é o Shell que o usuário vai receber ao se "logar", é para ser interpretado ao pé-da-letra, isto é, se neste campo do seu registro estiver prog, a pessoa ao acessar o sistema receberá a tela de execução do programa prog e ao terminar a sua execução ganhará imediatamente um logout. Imagine o quanto se pode incrementar a segurança com este simples artifício. Lembra que eu te falei de Shell , família, irmão? Pois é, vamos começar a entender isto: o Shell , que se vale da imagem de uma concha envolvendo o sistema operacional propriamente dito, é o nome genérico para tratar os filhos desta idéia que, ao longo dos anos de existência do sistema operacional Unix foram aparecendo. Atualmente existem diversos sabores de Shell , dentre estes eu destaco o sh (Bourne Shell), o ksh (Korn Shell), bash (Bourne Again Shell) e o csh (C Shell).
Uma Rapidinha nos Principais Sabores de Shell
Bourne Shell (sh)
Desenvolvido por Stephen Bourne da Bell Labs (da AT&T onde também foi desenvolvido o Unix ), este foi durante muitos anos o Shell default do sistema operacional Unix. É também chamado de Standard Shell por ter sido durante vários anos o único e até hoje é o mais utilizado até porque ele foi portado para todos os ambientes Unix e distros Linux.
Korn Shell (ksh)
Desenvolvido por David Korn, também da Bell Labs , é um superset do sh, isto é, possui todas as facilidades do sh e a elas agregou muitas outras. A compatibilidade total com o sh vem trazendo muitos usuários e programadores de Shell para este ambiente.
Boune Again Shell (bash)
Este é o Shell mais moderno e cujo número de adeptos mais cresce em todo o mundo, seja por ser o Shell default do Linux , seu sistema operacional hospedeiro, seja por sua grande diversidade de comandos, que incorpora inclusive diversos instruções características do C Shell.
C Shell (csh)
Desenvolvido por Bill Joy da Berkley University é o Shell mais utilizado em ambientes *BSD e Xenix. A estruturação de seus comandos é bem similar à da linguagem C. Seu grande pecado foi ignorar a compatibilidade com o sh, partindo por um caminho próprio.
Além destes Shells existem outros, mas irei falar contigo somente sobre os três primeiros, tratando-os genericamente por Shell e assinalando as especificidades de cada um que porventura hajam.
Explicando o funcionamento do Shell
O Shell é o primeiro programa que você ganha ao se "logar" no Linux. É ele que vai resolver um monte de coisas de forma a não onerar o kernel com tarefas repetitivas, aliviando-o para tratar assuntos mais nobres. Como cada usuário possui o seu próprio Shell interpondo-se entre ele e o Linux , é o Shell quem interpreta os comandos que são teclados e examina as suas sintaxes, passando-os esmiuçados para execução.
- Êpa! Esse negócio de interpreta comando não tem nada a haver com interpretador não, né?
- Tem sim, na verdade o Shell é um interpretador (ou será intérprete) que traz consigo uma poderosa linguagem com comandos de alto nível, que permite construção de loops (laços), de tomadas de decisão e de armazenamento de valores em variáveis, como vou te mostrar. Vou te explicar as principais tarefas que o Shell cumpre, na sua ordem de execução. Preste atenção nesta ordem porque ela é fundamental para o entendimento do resto do nosso bate papo.
Exame da Linha de Comandos
Neste exame o Shell identifica os caracteres especiais (reservados) que têm significado para interpretação da linha, logo após verifica se a linha passada é uma atribuição ou um comando.
Atribuição
Se o Shell encontra dois campos separados por um sinal de igual (=) sem espaços em branco entre eles , identifica esta seqüência como uma atribuição. Exemplos $ ls linux linux Neste exemplo o Shell identificou o ls como um programa e o linux como um parâmetro passado para o programa ls. $ valor= Neste caso, por não haver espaços em branco (já dá para notar que o branco é um dos caracteres reservados) o Shell identificou uma atribuição e colocou 1000 na variável valor. Jamais Faça:
(juntamente com o Shell filho), recebe novamente o controle e, exibindo um prompt , mostra que está pronto para executar outros comandos.
Decifrando a Pedra da Roseta
Para tirar aquela sensação que você tem quando vê um script Shell , que mais parece uma sopa de letrinhas ou um hieróglifo vou lhe mostrar os principais caracteres especiais para que você saia por ai como o Jean-François Champollion decifrando a Pedra da Roseta (dê uma "googlada" para descobrir quem é este cara, acho que vale a pena).
Caracteres para remoção do significado
É isso mesmo, quando não desejamos que o Shell interprete um caractere especial, devemos "escondê-lo" dele. Isso pode ser feito de três formas distintas:
Apóstrofo ou plic ( ' )
Quando o Shell vê uma cadeia de caracteres entre apóstrofos ('), ele tira os apóstrofos da cadeia e não interpreta seu conteúdo. $ ls linux* linuxmagazine $ ls 'linux' bash: linux no such file or directory No primeiro caso o Shell "expandiu" o asterisco e descobriu o arquivo linuxmagazine para listar. No segundo, os apóstrofos inibiram a interpretação do Shell e veio a resposta que não existe o arquivo linux*.
Contrabarra ou Barra Invertida ()
Idêntico aos apóstrofos exceto que a barra invertida inibe a interpretação somente do caractere que a segue. Suponha que você acidentalmente tenha criado um arquivo chamado * (asterisco) – que alguns sabores de Unix permitem - e deseja removê-lo. Se você fizesse: $ rm * Você estaria fazendo a maior encrenca, pois o rm removeria todos os arquivos do diretório corrente. A melhor forma de fazer o pretendido é: $ rm * Desta forma, o Shell não interpretaria o asterisco, e em conseqüência não faria a sua expansão. Faça a seguinte experiência científica: $ cd /etc
$ echo '*' $ echo * $ echo * Viu a diferença? Então não precisa explicar mais.
Aspas ( " )
Exatamente igual ao apóstrofo exceto que, se a cadeia entre aspas contiver um cifrão ($), uma crase (), ou uma barra invertida (\), estes caracteres serão interpretados pelo _Shell_. Não precisa se estressar, eu não te dei exemplos do uso das aspas por que você ainda não conhece o cifrão ($) nem a crase (). Daqui para frente veremos com muita constância o uso destes caracteres especiais, o mais importante é entender o significado de cada um.
Caracteres de redirecionamento
A maioria dos comandos tem uma entrada, uma saída e pode gerar erros. Esta entrada é chamada Entrada Padrão ou stdin e seu default é o teclado do terminal. Analogamente, a saída do comando é chamada Saída Padrão ou stdout e seu default é a tela do terminal. Para a tela também são enviadas por default as mensagens de erro oriundas do comando que neste caso é a chamada Saída de Erro Padrão ou stderr. Veremos agora como alterar este estado de coisas. Vamos fazer um programa gago. Para isto faça: $ cat O cat é uma instrução que lista o conteúdo do arquivo especificado para a Saída Padrão (stdout). Caso a entrada não seja definida, ele espera os dados da stdin. Ora como eu não especifiquei a entrada, ele está esperando-a pelo teclado (Entrada Padrão) e como também não citei a saída, o que eu teclar irá para a tela (Saída Padrão) fazendo desta forma, como eu havia proposto um programa gago. Experimente!
Redirecionamento da Saída Padrão
Para especificarmos a saída de um programa usamos o > (maior que) ou o >> (maior, maior) seguido do nome do arquivo para o qual se deseja mandar a saída. Vamos transformar o programa gago em um editor de textos (que pretensão heim!). $ cat > Arq O cat continua sem ter a entrada especificada, portanto está aguardando que os dados sejam teclados, porém a sua saída está sendo desviada para o arquivo Arq. Assim sendo, tudo que esta sendo teclado esta indo para dentro de Arq, de forma que fizemos o editor de textos mais curto e ruim do planeta.
O $$ contém o PID, isto é, o número do seu processo. Como o Linux é multiusuário, é bom anexar sempre o $$ ao nome dos dos arquivos que serão usados por várias pessoas para não haver problema de propriedade, isto é, caso você batizasse o seu arquivo simplesmente como seraqueexiste, o primeiro que o usasse (criando-o então) seria o seu dono e todos os outros ganhariam um erro quando tentassem gravar algo nele. Para que você teste a Saída de Erro Padrão direto no prompt do seu Shell , vou dar mais um exemplo. Faça: $ ls naoexiste bash: naoexiste no such file or directory $ ls naoexiste 2> arquivodeerros $ $ cat arquivodeerros bash: naoexiste no such file or directory Neste exemplo, vimos que quando fizemos um ls em naoexiste, ganhamos uma mensagem de erro. Após, redirecionarmos a Saída de Erro Padrão para arquivodeerros e executarmos o mesmo comando, recebemos somente o prompt na tela. Quando listamos o conteúdo do arquivo para o qual foi redirecionada a Saída de Erro Padrão, vimos que a mensagem de erro tinha sido armazenada nele. Faça este teste ai. Dica # 2
- Quem é esse tal de /dev/null?
- Em Unix existe um arquivo fantasma. Chama-se /dev/null. Tudo que é mandado para este arquivo some. Assemelha-se a um Buraco Negro. No caso do exemplo, como não me interessava guardar a possível mensagem de erro oriunda do comando rm, redirecionei-a para este arquivo. É interessante notar que estes caracteres de redirecionamento são cumulativos, isto é, se no exemplo anterior fizéssemos: $ ls naoexiste 2>> arquivodeerros a mensagem de erro oriunda do ls seria anexada ao final de arquivodeerros.
Redirecionamento da Entrada Padrão
Para fazermos o redirecionamento da Entrada Padrão usamos o < (menor que).
- E prá que serve isso? - você vai me perguntar.
- Deixa eu te dar um exemplo que você vai entender rapidinho. Suponha que você queira mandar um mail para o seu chefe. Para o chefe nós caprichamos, né? então ao invés de sair redigindo o mail direto no prompt da tela de forma a tornar impossível a correção de uma frase anterior onde, sem querer, escreveu
um "nós vai", você edita um arquivo com o conteúdo da mensagem e após umas quinze verificações sem constatar nenhum erro, decide enviá-lo e para tal faz: $ mail chefe < arquivocommailparaochefe O teu chefe então receberá o conteúdo do arquivocommailparaochefe.
Here Document
Um outro tipo de redirecionamento muito louco que o Shell te permite é o chamado here document. Ele é representado por << (menor menor) e serve para indicar ao Shell que o escopo de um comando começa na linha seguinte e termina quando encontra uma linha cujo conteúdo seja unicamente o label que segue o sinal <<. Veja o fragmento de script a seguir, com uma rotina de ftp: ftp -ivn hostremoto << fimftp user $Usuário $Senha binary get arquivoremoto fimftp Neste pedacinho de programa temos um monte de detalhes interessantes:
- As opções que usei para o ftp (-ivn) servem para ele ir listando tudo que está acontecendo (—v de verbose), para não perguntar se você tem certeza de que deseja transmitir cada arquivo (—i de interactive), e finalmente a opção —n serve para dizer ao ftp para ele não solicitar o usuário e sua senha, pois esses serão informados pela instrução específica (user);
- Quando eu usei o << fimftp, estava dizendo o seguinte para o intérprete:
- Olhe aqui Shell , não se meta em nada a partir daqui até encontrar o label fimftp. Você não entenderia nada, já que são instruções específicas do comando ftp e você não entende nada de ftp. Se fosse só isso seria simples, mas pelo próprio exemplo dá para ver que existem duas variáveis ($Usuário e $Senha), que o Shell vai resolver antes do redirecionamento. Mas a grande vantagem desse tipo de construção é que ela permite que comandos também sejam interpretados dentro do escopo do here document , o que também contraria o que acabei de dizer. Logo a seguir explico como esse negócio funciona. Agora ainda não dá, está faltando ferramenta.
- O comando user é do repertório de instruções do ftp e serve para passar o usuário e a senha que haviam sido lidos em uma rotina anterior a esse fragmento de código e colocados respectivamente nas duas variáveis: $Usuário e $Senha.
- O binary é outra instrução do ftp, que serve para indicar que a transferência de arquivoremoto será feita em modo binário, isto é, o conteúdo do arquivo não será interpretado para saber se está em ASCII, EBCDIC, ...
$ who | wc -l 8 O comando who passa a lista de usuários conectados para o comando wc –l que conta quantas linhas recebeu e lista a resposta na tela. Pois bem, mas ao invés de ter um oito solto na tela, o que eu quero é que ele esteja no meio de uma frase. Ora para mandar frases para a tela eu uso o comando echo, então vamos ver como é que fica: $ echo "Existem who | wc -l usuários conectados" Existem who | wc -l usuários conectados Hi! Olha só, não funcionou! É mesmo, não funcionou e não foi por causa das aspas que eu coloquei, mas sim por que eu teria que ter executado o who | wc -l antes do echo. Para resolver este problema, tenho que priorizar esta segunda parte do comando com o uso de crases, fazendo assim: $ echo "Existem who | wc -l usuários conectados" Existem 8 usuários conectados Para eliminar esse monte de brancos antes do 8 que o wc -l produziu, basta tirar as aspas. Assim: $ echo Existem who | wc -l usuários conectados Existem 8 usuários conectados Como eu disse antes, as aspas protegem tudo que esta dentro dos seus limites, da interpretação do Shell. Como para o Shell basta um espaço em branco como separador, o monte de espaços será trocado por um único após a retirada das aspas. Antes de falar sobre o uso dos parênteses deixa eu mandar uma rapidinha sobre o uso de ponto-e-vírgula (;). Quando estiver no Shell , você deve sempre dar um comando em cada linha. Para agrupar comandos em uma mesma linha teremos que separá-los por ponto-e-vírgula. Então: $ pwd ; cd /etc; pwd; cd -; pwd /home/meudir /etc/ /home/meudir Neste exemplo, listei o nome do diretório corrente com o comando pwd, mudei para o diretório /etc, novamente listei o nome do diretório e finalmente voltei para o diretório onde estava anteriormente (cd -), listando seu nome. Repare que coloquei o ponto-e-vírgula (;) de todas as formas possíveis para mostrar que não importa se existe espaços em branco antes ou após este caractere. Finalmente vamos ver o caso dos parênteses. Veja só o caso a seguir, bem parecido com o exemplo anterior:
$ (pwd ; cd /etc ; pwd;) /home/meudir /etc/ $ pwd /home/meudir
- Quequeiiisso minha gente? Eu estava no /home/meudir, mudei para o /etc, constatei que estava neste diretório com o pwd seguinte e quando o agrupamento de comandos terminou, eu vi que continuava no /home/meudir, como se eu nunca houvesse saído de lá!
- Ih! Será que é tem coisa de mágico aí?
- Tá me estranhando, rapaz? Não é nada disso! O interessante do uso de parênteses é que ele invoca um novo Shell para executar os comandos que estão no seu interior. Desta forma, realmente fomos para o diretório /etc, porém quando todos os comandos dentro dos parênteses foram executados, o novo Shell que estava no diretório /etc morreu e voltamos ao Shell anterior cujo diretório corrente era /home/meudir. Faça outros testes usando cd, e ls para você firmar o conceito. Agora que já conhecemos estes conceitos veja só este exemplo a seguir: $ mail suporte << FIM
Ola suporte, hoje as ‘date "+%H:%M"‘ ocorreu novamente aquele problema que eu havia reportado por telefone. Conforme seu pedido ai vai uma listagem dos arquivos do diretorio: ‘ls —l‘ Abracos a todos. FIM Finalmente agora temos conhecimento para mostrar o que havíamos conversado sobre here document. Os comandos entre crases (`) serão priorizados e portanto o Shell os executará antes da instrução mail. Quando o suporte receber o e-mail , verá que os comandos date e ls foram executados imediatamente antes do comando mail, recebendo então uma fotografia do ambiente no momento em que a correspondência foi enviada. O prompt primário default do Shell , como vimos, é o cifrão ($), porém o Shell usa o conceito de prompt secundário, ou de continuação de comando, que é enviado para a tela quando há uma quebra de linha e a instrução não terminou. Esse prompt , é representado por um sinal de maior (>), que vemos precedendo a partir da 2ª linha do exemplo. Para finalizar e bagunçar tudo, devo dizer que existe uma construção mais moderna que vem sendo utilizada como forma de priorização de execução de comandos, tal qual as
- Pô, saiu tudo embolado!
- Pois é cara, como eu já te disse, se você deixar o Shell “ver” os espaços em branco, sempre que houver diversos espaços juntos, eles serão trocados por apenas um. Para que a listagem saia bonitinha, é necessário proteger a variável da interpretação do Shell , assim: $ echo "$Arqs" -rw-r--r-- 1 jneves jneves 19 May 24 19: arq -rw-r--r-- 1 jneves jneves 23 May 24 19: arq -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql
- Olhe, amigo, vá treinando esses exemplos, porque, quando nos encontrarmos novamente, vou lhe explicar uma série de instruções típicas de programação Shell. Tchau! Ahh! Só mais uma coisinha que eu ia esquecendo de lhe dizer. Em Shell , o "jogo da velha" (#) é usado quando desejamos fazer um comentário. $ exit # pede a conta ao garcon Vou aproveitar também para mandar o meu jabá: diga para os amigos que quem estiver afim de fazer um curso porreta de programação em Shell que mande um e-mail para a nossa gerencia de treinamento para informar-se. Qualquer dúvida ou falta de companhia para um chope ou até para falar mal dos políticos é só mandar um e-mail para mim. Valeu! (CC) 2008 Pelos Frequentadores do Bar do Júlio Neves. Todo o conteúdo desta página pode ser utilizado segundo os termos da Creative Commons License: Atribuição-UsoNãoComercial-PermanênciaDaLicença. \
Aqui temos um livro livre e completo sobre Shell
Os sedentos do "saber livre" são muito benvindos.
● [ 01 Apr 2008 - 19:02 ] Links Amigos ● BR-Linux ● Viva o Linux ● Dicas-L
● Aurelio ● Thobias
- TWIKI BÁSICO o Página Inicial o Últimas Alterações o Índice o Procura o Estatísticas de Uso o Aviso de Atualização o Mapa do Site
- TWIKI AVANÇADO o Registre-se o Configurações Gerais o Quem Somos o Regras de Formatação o Biblioteca Gráfica o Carinhas Gráficas
- PROJETO GRÁFICO o Pré Tópico o Pós Tópico o Menu Lateral o Menu de Navegação o CSS Utilizado o Botões Especiais o Indica Onde Estamos o Cabeçalho Padrão o Copy Right/Left Você está aqui: TWikiBar > BatePapos > TWikiBarPapo Controles: - Última Atualização: [15 Jan 2008 - V.22]
Papo de Botequim Parte II
● Eu fico com o grep, você com a gripe o A família grep ● Vamos Montar uma "cdteca" o Passando parâmetros o Macetes paramétricos
- Garçom! Traz um "chops" e dois "pastel". O meu amigo hoje não vai beber por que ele finalmente está sendo apresentado a um verdadeiro sistema operacional e ainda tem muita coisa a aprender!
- E então, amigo, tá entendendo tudo que te expliquei até agora?
- Entendendo eu tô, mas não vi nada prático nisso...
- Calma rapaz, o que te falei até agora, serve como base ao que há de vir daqui pra frente. Vamos usar estas ferramentas que vimos para montar programas estruturados,
A família grep
Este comando grep é muito conhecido, pois é usado com muita freqüência, o que muitas pessoas desconhecem é que existem três comandos na família grep, que são: ● grep ● egrep ● fgrep A principais características diferenciais entre os 3 são: ● O grep pode ou não usar expressões regulares simples, porém no caso de não usá-las, o fgrep é melhor, por ser mais rápido; ● O egrep ("e" de extended, extendido) é muito poderoso no uso de expressões regulares. Por ser o mais lento da família, só deve ser usado quando for necessária a elaboração de uma expressão regular não aceita pelo grep; ● O fgrep ("f" de fast, rápido, ou de "file", arquivo) como o nome diz é o rapidinho da família, executa o serviço de forma muito veloz (por vezes é cerca de 30% mais veloz que o grep e 50% mais que o egrep), porém não permite o uso de expressões regulares na pesquisa. Tudo que foi dito acima sobre velocidade, só se aplica à família de comandos grep do Unix. No Linux o grep é sempre mais veloz, já que os outros dois (fgrep e egrep) são scripts em Shell que chamam o primeiro e, já vou adiantando, não gosto nem um pouquinho desta solução.
- Agora que você já conhece as diferenças entre os membros da família, me diga: o que você acha dos três exemplos que eu dei antes das explicações?
- Eu achei que o fgrep resolveria o teu problema de forma mais veloz do que o grep.
- Perfeito! Tô vendo que você está atento! Está entendendo tudo que estou te explicando! Então vamos ver mais exemplos para clarear de vez as diferenças de uso dos membros da família. Exemplos Eu sei que em um arquivo existe um texto falando sobre Linux só não tenho certeza se está escrito com L maiúsculo ou l minúsculo. Posso fazer de duas formas: $ egrep (Linux | linux) arquivo.txt ou $ grep [Ll]inux arquivo.txt
No primeiro caso, a expressão regular complexa "(Linux | linux)" usa os parênteses para agrupar as opções e a barra vertical (|) como um "ou" lógico, isto é, estou procurando Linux ou linux. No segundo, a expressão regular [Ll]inux significa: começado por L ou l seguido de inux. Por esta expressão ser mais simples, o grep consegue resolvê-la, portanto acho melhor usar a segunda forma, já que o egrep tornaria a pesquisa mais lenta. Outro exemplo. Para listar todos os subdiretórios do diretório corrente, basta: $ ls -l | grep '^d' drwxr-xr-x 3 root root 4096 Dec 18 2000 doc drwxr-xr-x 11 root root 4096 Jul 13 18: freeciv drwxr-xr-x 3 root root 4096 Oct 17 2000 gimp drwxr-xr-x 3 root root 4096 Aug 8 2000 gnome drwxr-xr-x 2 root root 4096 Aug 8 2000 idl drwxrwxr-x 14 root root 4096 Jul 13 18: locale drwxrwxr-x 12 root root 4096 Jan 14 2000 lyx drwxrwxr-x 3 root root 4096 Jan 17 2000 pixmaps drwxr-xr-x 3 root root 4096 Jul 2 20: scribus drwxrwxr-x 3 root root 4096 Jan 17 2000 sounds drwxr-xr-x 3 root root 4096 Dec 18 2000 xine No exemplo que acabamos de ver, o circunflexo (^) serviu para limitar a pesquisa à primeira posição da saída do ls longo. Os apóstrofos foram colocados para o Shell não "ver" o circunflexo (^). Vamos ver mais um. Sabemos que as quatro primeiras posições possíveis de um ls -l de um arquivo comum (arquivo comum! Não é diretório, nem link , nem ...) devem ser: Posição
Valores Possíveis
Assim sendo, para descobrir todos os arquivos executáveis em um determinado diretório eu deveria fazer: $ ls -la | egrep '^-..(x|s)' -rwxr-xr-x 1 root root 2875 Jun 18 19:38 rc
