Jump to content
Sign in to follow this  
Manimal

Nome Completo dos Arquivos

Recommended Posts

Olá pessoal.


Em uma dúvida recente aqui no fórum, um bug foi resolvido (ou criado) porque não foi informado o nome completo do arquivo.

Nestes anos de programação, vi muitos erros neste sentido ao trabalhar com arquivos, tantos erros meus como de tereceiros.

Então por padrão, decidi há muito tempo atrás, padronizar meus programas sempre com o nome completo dos arquivos, até para evitar dores de cabeça de graça.


Porém percebi que muitos não sabem o que é nome completo do arquivo e que esta não é uma dúvida de AutoIt, mas de operação de computadores de um modo geral.

Assim em qualquer função onde é informado um nome de arquivo, devemos ter o cuidado de sempre informar o nome completo, ou se não o fizermos, sabermos exatamente o que estamos omitindo e porquê.


Todo arquivo tem seu NOME COMPLETO dividido em 4 (quatro) partes. Essas partes são:

  1. LOCAL = em qual unidade ou lugar da rede que está localizado o arquivo

  2. CAMINHO = qual a estrutura de pastas e subpastas onde está localizado o arquivo

  3. NOME = nome efetivo do arquivo

  4. EXTENSÃO = sufixo que identifica o tipo do arquivo (úti para algumas funções do SO = Sistema Operacional)


Não se enganem, TODOS os arquivo seguem esta terminologia, em qualquer linguagem ou sistema seja Windows, Linux ou qualquer outro.

Destas 4 partes podemos "esquecer" ou "deixar de informar" até 2 partes:

  • LOCAL e/ou CAMINHO

Mas se não informamos, o SO vai "preencher" estas informações porque ele SEMPRE necessita das 4 partes (NOME COMPLETO).

E talvez esse preenchimento não seja o mais adequado as nossas necessidades do programa naquele momento dando margem a erros e bugs inexplicáveis!


Vou explicar melhor através de exemplos:



C:\ARQUIVO.TXT
   LOCAL = C:
   CAMINHO = \
   NOME = ARQUIVO
   EXTENSÃO = .TXT



D:\MEU DOCS\DOWNLOADS\FILMES.XML
   LOCAL = D:
   CAMINHO = \MEU DOCS\DOWNLOADS\
   NOME = FILMES
   EXTENSÃO = .XML



\\192.168.1.11\USERS\FULANO\DESKTOP\LIVRO.PDF
   LOCAL = \\192.168.1.11
   CAMINHO = \USERS\FULANO\DESKTOP\
   NOME = LIVRO
   EXTENSÃO = .PDF


E assim por diante. Não é difícil e normalmente fazemos isso (NOME COMPLETO) sem perceber.

Porém ao programarmos, temos o hábito de esquecer destas 4 partes e colocamos apenas:



Arquivo = "PROGRAMA.EXE"
 ou 
FileRead("NOMES.TXT")
 ou
IniRead("CONFIG.INI", ...)


Quando deixamos de informar o nome completo, o SO precisa completar todos os campos para poder processar o arquivo.

Nos casos acima, onde foi informado apenas as partes 3 e 4 de cada nome, as partes 1 e 2 serão preenchidas com o padrão do SO naquele momento.

Assim, internamente a função FileRead vai assumir a unidade e pasta atual do programa para completar as informações necessárias.


Isso é muito bom e funciona certinho quando clicamos 2x no arquivo dentro de uma pasta por exemplo.

Mas e se chamamos o programam (script) através de um arquivo BAT (ou CMD). E se executarmos nosso script a partir do comando EXECUTAR do Windows.

De qual pasta ele irá completar as partes faltantes?


Por isso recomendo que em todas as operações de arquivo, tenhamos por hábito informar TODAS as partes do nome dos arquivo que trabalhamos.



$Arquivo = @ScriptDir & "\PROGRAMA.EXE"
 ou 
FileRead("C:\PASTA\NOMES.TXT")
 ou
IniRead("D:\MEUPROG\CONFIG.INI", ...)


São pequenas alterações que resolvem grandes problemas.


Aproveitem e usem as macros do AutoIt que dizem que pasta estamos

  • @ScriptDir

  • @ScriptName

  • @ScriptFullPath

como base para o nome dos seus arquivos.


Também é perfeitamente possível o uso das referências relativas como "..\" ou ".\", mas devem ser muito bem trabalhadas, com bastante atenção.

As operações com arquivos que mais incomodam são as de copiar, renomear ou apagar arquivos. As que mudam alguma característica como data e/ou hora também são exigentes.


#FikaDika ;)

  • Like 3

Share this post


Link to post
Share on other sites

Quando eu quero que um programa gerencie outro programa se baseando nos diretórios ou nos nomes das pastas eu uso a UDF "_PathSplit.au3". Ele é parecido com o sistema do autoit, mas ele retorna a pasta pai dos arquivos. Eu tinha criado um programa que executava algo a partir de uma linha de comando com o nome da pasta.

Ex:

C:/programas/jogos/gta.exe

C:/

/programas/jogos/

/jogos/

gta

.exe

 

 

Outro também é um programa que eu fiz que executa o programa com a linha de comando Ex: "avast" e ele ia diretamente na pasta do arquivo com base na linha de comando.

ShellExecute("setup.exe", "", & @scriptdir & "\" & CmdLine[1] & "\", "open",@SW_SHOW)
Edited by Pedro Pinheiro
  • Like 1

Share this post


Link to post
Share on other sites

Eu sempre coloco o Caminho Completo mesmo.

 

E ADORO usar as Macros como manda o figurino. :muttley:

  • @ScriptDir
  • @ScriptName
  • @ScriptFullPath

Já vi muitos scripts por aqui que a galera usa só FileRead("NOMES.TXT") como você disse mesmo. :P

 

Ótima dica. :up:

  • Like 1

Share this post


Link to post
Share on other sites

Destas 4 partes podemos "esquecer" ou "deixar de informar" até 2 partes: LOCAL e/ou CAMINHO

 

Mas a extensão pode ser ignorada também né?

 

Ou no autoit não rula, se acessar o arquivo sem extensão?

Share this post


Link to post
Share on other sites

Olá Joelson0007.

 

A extensão também não pode ser "esquecida", exceto em 3 (três) situações:

 

1) o arquivo não possui ou não tem extensão. Ex. C:\Pasta\Arquivo

 

2) a extensão é parte de um arquivo de uma operação registrada no SO. Como arquivos PDF ou arquivos DOC (ou DOCX) são extensões naturais e conhecidas do SO.

Assim ao chamarmos uma extensão registrada, o SO completa a extensão assumindo o padrão.

Portanto ao chamarmos um programa externo ele mesmo completa a extensão:

Run("C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AcroRd32.exe C:\Pasta\Arquivo")

Neste exemplo, vai abrir o Adode PDF Reader que por sua vez vai tentar abrir C:\Pasta\Arquivo, assumindo .PDF como extensão. Se não existir o Arquivo.PDF ou não existir o Arquivo em si, dá erro.

Mas porque o Reader assume que quaisquer arquivos abertos por ele (Reader) sejam PDF. A mesma coisa ocorre com o Word ou Excel.

 

Outro exemplo é o comando em AutoIt, INIREAD:

IniRead("C:\Pasta\Arquivo", ...)

Neste caso o comando entende que a extensão é .INI. Se não for, deve ser explicitado!

IniRead("C:\Pasta\Arquivo.MEM", ...)

3) Finalmente, a extensão é de programas ditos "executáveis" padrão:

  • .EXE
  • .COM
  • .BAT
  • .CMD

Nestes casos o SO assume que o arquivo em questão é um "executável", completa com um cada uma das 4 extensões e procura-os em vários locais como pasta atual e no PATH.

 

Exemplo:

Run("Notepad")

Isso funciona por que o SO entende várias coisas:

É um programa executável, então ele "completa" o comando com a extensão .EXE e procura na pasta atual do script. Se não achar, procura em cada uma das pastas do PATH. Não achou ainda? Então troca a extensão por .COM e repete a procura. Não achou de novo? Vai para a extensão .BAT e para a extensão .CMD. Finalmente se não achou nenhuma das variantes anteriores dá erro!

 

Mas se tentarmos:

Run("C:\Pasta\Arquivo.mem")

ou

Run("Notepad.EXT")

Vai dar erro porque nenhuma das extensões é "executável"

 

Mas existe uma diferença importante. Veja que usei o comando RUN - que exige executáveis.

Se usarmos outro comando como o ShellExecute o comportamento é muito similar mas com uma grande vantagem: Podemos usar "executáveis" ou "arquivos registrados" no SO.

ShellExecute("Notepad")

Tem o mesmo comportamento de antes (completa a extensão, blá blá blá...)

Mas se tentarmos

ShellExecute("C:\Pasta\Arquivo.TXT")

Observe que o arquivo não é "executável", mas a extensão é registrada padrão.

Devido ao comportamento do ShellExecute, ele procura o programa registrado para a extensão .TXT, abre este programa que vai finalmente abrir o C:\Pasta\Arquivo.txt

A vantagem disso é que podemos chamar certos arquivos usando apenas a extensão registrada, seja qual programa associado for.

 

Deu pra entender?

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×