Un poco raro. Estoy usando Excel para analizar algunos datos que tengo en varios archivos .txt.
Cuando estoy tratando de importarlos a través de Data
> Get External Data
> Import Text File
:
Como lo he hecho muchas veces en el pasado, aparece el cuadro de diálogo "Elegir un archivo", pero cuando busco la carpeta, solo un par de archivos son "seleccionables"; los otros están "en gris":
No hay diferencias entre los archivos que puedo ver que justifiquen la diferencia. La única "lógica" es que el archivo "fuente" (llamémoslo 20150728 - SOURCE.TXT
) viene por correo electrónico desde una máquina con Windows, y los otros dos archivos bloqueados ( 20150728 - Source Fragment 3.TXT
y 20150728 - Source Fragment 3 copy.TXT
) son una copia de la Fuente donde eliminé algunas líneas, y un segunda copia del archivo resultante, mientras que los no bloqueados comenzaron como la Fuente donde eliminé líneas, y luego hice "Guardar como" en TextWrangler...
Puedo solucionar el problema simplemente copiando el contenido de los archivos " en gris" en un nuevo documento en TextWrangler y guardándolo, pero me gustaría entender el motivo de este comportamiento.
Hacer un file
en los archivos en cuestión muestra que son similares, si no iguales:
Mac:samples jjarava$ file 201507*txt
20150728 - Source Fragment 3.TXT: ASCII text
20150728 - Source Framgent 1.TXT: ASCII text
20150728 - Source Fragment 1.TXT: ASCII text
20150728 - Source.TXT: ASCII text, with CRLF line terminators
20150728 - Source Fragment 3 copy.TXT: ASCII text
Estoy un poco "atascado" en cuál podría ser el problema. Tengo la sensación de que es uno de esos "obscuros caprichos de Mac" que son muy difíciles de explicar.
EDITAR : según los comentarios a continuación de @ user3439894 y otros, he examinado los atributos extendidos de los archivos para ver si eso da alguna pista.
La salida de ls -l@
para los archivos nos da:
-rw-r--r--@ 1 jjarava staff 7652 Aug 3 13:58 20150728 - Source Fragment 3 (BAD).TXT
com.apple.FinderInfo 32
com.apple.TextEncoding 15
com.dropbox.attributes 83
-rw-r--r--@ 1 jjarava staff 6570 Aug 3 13:58 20150728 - Source Fragment 1 (Good).TXT
com.apple.FinderInfo 32
com.apple.TextEncoding 15
com.dropbox.attributes 83
-rw-r--r--@ 1 jjarava staff 6616 Aug 3 13:58 20150728 - Source Fragment 2 (Good).TXT
com.apple.FinderInfo 32
com.apple.TextEncoding 15
com.dropbox.attributes 83
-rw-r--r--@ 1 jjarava staff 21138 Aug 3 13:58 20150728 - Source (BAD).TXT
com.apple.FinderInfo 32
com.dropbox.attributes 83
De nuevo, veo que a uno de los archivos malos (Fuente) aparentemente le falta el com.apple.TextEncoding
atributo, pero el otro archivo "no funciona" sí tiene el atributo... En caso de que los valores sean diferentes para los archivos buenos y malos, vamos a controlar:
Mac:samples jjarava$ xattr -p com.apple.TextEncoding 201507*txt
20150728 - Source Fragment 3 (BAD).TXT: UTF-8;134217984
Source Fragment 1 (Good).TXT: UTF-8;134217984
Source Fragment 2 (Good).TXT: UTF-8;134217984
xattr: 20150728 - Source (BAD).TXT: No such xattr: com.apple.TextEncoding
Así que ese tampoco parece ser el truco...
Creo que tengo una respuesta.
Buscando en Google, encontré referencias a problemas "en gris" y menciones del creator
atributo del archivo.
Entonces, un rápido Google para " marca de creador de archivos osx " me señaló a mí SetFile
y a su hermano GetFileInfo
.
Ejecutando un rápido GetFileInfo
en los archivos que obtengo:
Mac:samples jjarava$ for i in 201507*.TXT; do getfileinfo "$i"; echo .; done
file: "/path/to/samples/20150728 - Source Fragment 3 (BAD).TXT"
type: "????"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source Framgent 1 (Good).TXT"
type: "TEXT"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source Framgent 2 (Good).TXT"
type: "TEXT"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source (BAD).TXT"
type: "????"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source Fragment 3 copy (BAD).TXT"
type: "????"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
Todos los archivos "en funcionamiento" son de type: "TEXT"
, y todos los que "no funcionan" parecen no tener un "tipo" definido...
En realidad, ejecutando lo siguiente para cambiar el archivo type
:
Mac:samples jjarava$ setfile -t TEXT "20150728 - Source Fragment 3 copy (BAD).TXT"
Mac:samples jjarava$ getfileinfo "20150728 - Source Fragment 3 copy (BAD).TXT"
file: "/path/to/samples/20150728 - Source Fragment 3 copy (BAD).TXT"
type: "TEXT"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
¡Y ese archivo ahora se puede seleccionar en el cuadro de diálogo "Abrir" en Excel!
La pregunta es de dónde viene el campo "tipo" y por qué está configurado en algunos archivos y no en otros, ¡pero al menos hay algo de "lógica" en el problema!
Source
archivo desde mi programa de correo electrónico; claramente esa es la raíz del problema...cut
) grep
y canalizarlos a nuevos archivos todavía tengo el problema para importarlos para su procesamiento. Establecer el tipo en TEXTO SetFile
resolvió el problema.Bueno, como muestra su captura de pantalla, son "casi", pero no completamente iguales; el archivo original es ASCII text, with CRLF line terminators
mientras que las copias y los fragmentos que creó son ASCII text
.
Algunos antecedentes: si piensa en una máquina de escribir antigua, suceden cosas, cuando el escritor comienza una nueva línea: el papel se "hace avanzar" una línea ("avance de línea", LF) y el carro se mueve a la posición más a la izquierda (="retorno de carro", CF). UNIX y OS X usan un solo carácter LF para hacer ambas cosas en archivos de texto; Windows, por otro lado, usa dos caracteres, un CR y un LF, al final de cada línea.
Aparentemente, la función de importación de Excel no puede manejar el archivo de texto "formateado en Windows"; TextWrangler, por otro lado, puede y, cuando manipula el archivo y guarda una copia, lo guarda automáticamente en "formato UNIX", convirtiendo los CRLF en LF. Su solución es decirle a lo que crea esos archivos en la máquina de Windows, guardarlos en formato UNIX o convertirlos a formato UNIX en OS X, antes de poder importarlos a Excel.
Source
archivo? Eso es lo que me desconcierta...
usuario3439894
20150728 - Source.TXT: ASCII text, with CRLF line terminators
. Intente reemplazar los terminadores de línea CRLF con solo LF. En una Terminal, intente:tr -d '\r' < input.file > output.file
jjarava
Source
asegurarmeSource 3
de que los finales de línea fueran "Unix" en TextWrangler. Como puede ver, los otros archivos que no funcionan sonLF
usuario3439894
jjarava
usuario3439894
file
ya mostró que, sin embargo, el diseño es lo que me interesa, ¿cómo se delimita? ¿Y cuál es ells -l@
resultado de los archivos atenuados?RAM
jjarava
[28/07/15 13:32:02.538][ WARN]Tiempo SDPTRU02: 361 || Resultado: 0
: nada especial y, en cualquier caso, no creo que Excel esté analizando previamente los archivos; este es un cuadro de diálogo Abrir en el sistema operativo. Si el archivo tuvo problemas con el contenido, espero que Excel se queje después de que se haya seleccionado para abrirRAM
ls -l
Eso le indicará las banderas establecidas en los archivos. Puede ser que los archivos de texto atenuados se configuraron como de solo lectura.usuario3439894
ls -l@
porque quiero saber sicom.apple.quarantine
está configurado y, de ser así, eliminarloxattr -d com.apple.quarantine filename
y luego ver si se abre el archivo.jjarava
Source
archivo, elimine algunas líneas adicionales y luego Guardar como... para el Fragmento 1 y 2. En el caso del Fragmento 3, fue ligeramente diferente... Lo hice una copia de Fuente, cambie el nombre a Fragmento 3, Abra en TextWrangler, elimine el contenido adicional y Guarde.