envpathp - Online na nuvem

PROGRAMA:

NOME

envpath - operações avançadas em variáveis ​​de caminho

SINOPSE

Execute este script com a opção "-help" para detalhes de uso.

DESCRIÇÃO

Analisa a linha de comando, modifica as variáveis ​​de caminho especificadas e executa o restante
argumentos. Existem dois modos, simples e avançado:

SIMPLES MODA
O modo simples apresenta uma sintaxe alternativa e independente de plataforma para especificar caminhos
em que o separador de caminho é "," e as variáveis ​​de ambiente podem ser expandidas com @ NAME @.
Por exemplo

envpath PATH = @ PATH @, / usr / ucb - printenv PATH

acrescenta "/ usr / ucb" a $ PATH e execs printenv PATH. O "-" é opcional.

Você também pode especificar prefixar ou acrescentar usando "+ =" ou "= +" respectivamente:

# coloque / usr / ucb na frente
envpath PATH + = / usr / ucb - printenv PATH

# coloque / usr / ucb na parte de trás
envpath PATH = + / usr / ucb - printenv PATH

O modo simples requer apenas este script; não requer que Env :: Path seja instalado.

ADVANCED MODA
O modo avançado basicamente fornece acesso de linha de comando aos recursos de Env :: Path (consulte),
que deve ser instalado. O sinalizador "-E" seleciona a variável de caminho para operar e outras
sinalizadores especificam operações nele. Por exemplo

envpath -E MANPATH -A / Tmp -R / usr / share / man -N-U - cara ...

levaria MANPATH, anexaria / Tmp a ele, remova todas as referências a "/ usr / share / man", retirar
qualquer diretório que não exista ("-N") e remova as entradas redundantes ("-U") antes de executar homem.

A opção -Onde permite padrões. Assim

envpath -W "cat *"

encontraria todos os programas em PATH que correspondessem a cat *.

CAIXA PISCINA

Uma grande parte da motivação para este script era para uso com compilações ClearCase; se você
saber ou se preocupar com a leitura do ClearCase. Normalmente, durante as compilações (e não apenas com
ClearCase), pathvars como PATH, CLASSPATH e LD_LIBRARY_PATH devem ser estritamente
controlada. Uma opção é forçar os valores estáticos destes no ambiente durante o
processo de construção, outro é simplesmente exigir / esperar que os usuários definam seus caminhos de forma adequada.
Cada um deles pode levar a erros sutis de compilação ou tempo de execução, no entanto, e torna difícil para
novos usuários para se familiarizarem com a velocidade, já que seu ambiente pessoal deve ser adequado.

Outra escolha comum é usar apenas nomes de caminho completos dentro do Makefile, evitando a dependência
em caminhos de pesquisa. Muitas vezes, essa é a melhor maneira de fazer, mas pode suprimir o ClearCase
winkins. Por exemplo, digamos que você esteja gerando arquivos ascii de algum tipo com um binário
executável que você acabou de construir:

$ (INCDIR) /foo.h: $ (BINDIR) / foomaker $ (BINDIR) / foomaker ...

O problema com isso é que $ (BINDIR) provavelmente contém uma parte da plataforma, como 'solaris'
ou 'hpux', o que torna impossível piscar no arquivo foo.h em outras plataformas, mesmo
embora seja ascii. Essa mesma coisa pode acontecer até mesmo com um utilitário padrão pré-construído
que está em lugares diferentes em plataformas diferentes; "yacc", por exemplo, está em / usr / bin on
Linux e / usr / ccs / bin no Solaris.

Você pode modificar o caminho imediatamente:

$ (INCDIR) /foo.h: $ (BINDIR) / foomaker PATH = $ (BINDIR) $ (SEP) $$ PATH foomaker ...

mas isso sofre do mesmo problema: uma vez que $ (BINDIR) e $ PATH são expandidos literalmente
dentro do script de construção, eles suprimirão os winkins. Aqui está uma solução usando caminho do ambiente:

$ (INCDIR) /foo.h: $ (BINDIR) / foomaker envpath PATH = @ BINDIR @, @ PATH @ foomaker ...

Isso oculta a avaliação de BINDIR e PATH de modo que limpar nunca vê nada além
os literais, limpando assim o campo para winkins. Claro caminho do ambiente é capaz de fazer
mais do que isso, mas é o motivo original pelo qual foi escrito.

Use envpathp online usando serviços onworks.net