Barrapunto

Irónicamente, Slash no me ha dejado meter todo   en la línea de departamento. Me añadía espacios gratis. Suele pasar también cuando hay cadenas largas sin espacios (como en los URLs)

Si no me equivoco el fallo era cuando tenias dos discos duros /particiones cuyos nombre tenian espacios y la parte anterior al espacio del nombre era igual ejeplo "Particion Uno" "Particion Dos". Yo como las llamo como "Home" "Swap" "Var" (Seran porque vengo de linux ?) etc no he tenido problemas.

La verdad es que estoy muy contento con el , Tengo un unix , una buena maquina virtual java y un entorndo de escritorio productivo. No lo usaria en un servidor pero para mi portatil me resulta mas comodo que la combiandion (Win/Linux) o (VMWare/Linux) . Aun tengo que probar el linux PPC :) debe ser la ostia !!!

el fallo se debe a que los programadores de Unix (MacOS X es BSD por debajo) no están acostumbrados a pensar que los nombres de fichero pueden tener espacios en blanco.

  Menudo pedazo de tonteria han encontrado como excusa. Unix soporta espacio en los nombres de directorio antes de que Apple existiese y que su creador supiese qué es un ordenador. Y para los programadores nunca ha sido un problema, porque los directorios se llaman como cadenas de texto, y las cadenas siempre han usado como delimitadores el carácter de código "0". Para Unix el espacio es tán válido como cualquier otro caracter; y cualquiera puede hacer desde tiempos inmemoriales:

mkdir esto\ tiene\ muchos\ espacios

o

mkdir "Con mil cañones por banda, viento en popa a toda vela, no corta el mar sino vuela un velero bergantín. Bajel pirata que llaman, por su bravura, el temido; en todo mar conocido, del uno al otro confín."
 

Pero es que es verdad que no estamos acostumbrados. La mayoría de los scripts que hay por ahí cascan si hay ficheros con espacios en el nombre.

Por ejemplo, es corriente ver:

find . -type f -print | xargs grep pepe

Eso casca con espacios, hay que recurrir a:

find . -type f -print0 | xargs -0 grep pepe

Y lo malo es que esto último no es estándar.

pos que aprendan coño que ya va siendo hora. tampoco es intuitivo levantarse por la mañana temprano y bien que nos jodemos la mayoria.

Bueno, tengo un Linux PPC 99, y un 2000, que por diversas circustancias no he podido instalar por mi mismo, pero que varios amigos del resto de españa me han pedido, se han instalado, y no se han quejao... Bueno, el otro día ufi a instalarlo en un iBook blanco de los nuevos y el modo gráfico no arranca, pero me parece que bajandose una imagen nueva que había en la web, y complementandolo con los originales (que tengo) se arreglaba. Que por cierto, parece que soy el unico en españa que se lo ha comprado y anda con una camiseta por la calle... ¿Alguien más se lo compró? Aparte de eso, he visto correr por ahí una Suse 7 PPC sin problemas aparentes tampoco, aparte de un problema de configuración, que como es de configuración, pos le echamos a culpa al que lo ha instalao y arreglao... xD de rendimiento si que no te puedo decir nada... :P

Después de 30 años creo que no hay dudas sobre el manejo de espacios en los nombres de archivo por parte de Unix.
En *cualquier* sistema operativo que tenga un intérprete de comandos, debe haber un caracter separador de parámetros; en Unix, MSDOS, Plan 9, etc, es el espacio. En alguno de IBM es la coma, por ejemplo.
Es una regla *clara* y bien conocida. Todo aquél que haga un script para Unix debe tenerlo en cuenta, creo yo. No veo problemas de ambigüedad en ninguna parte.
El usuario procedente de un sistema operativo exclusivamente gráfico puede tener problemas con esto; no puedes abrir una ventana en un Mac y escribir la lista de nombres de archivo sobre los que hacer una operación, caso en el que necesitarías un separador. Los seleccionas a ratonazos.
Los programadores de Mac que pasen a MacOS X necesitan un pequeño ajuste de actitud, eso es todo.

jejejeeJejeje, muy bueno el comentario.

En el fondo tienes razón. Güindous es - aparte de un virus a gran escala - una forma de deseducar a los usuarios. Con güindous (TM) ya no hay directorios, sólo hay carpetas, no hay archivos o ficheros, sólo hay fotos, mp3, documentos de güord y ya está.

De hecho, en un futuro no muy lejano, existirán servicios de traducción en los servicios de soporte técnico: Mexplico: "Resulta que arranco un fax y entonces la CPU me dice que no encuentra dicho fax y que va a volver a empezar porque por lo visto en las carpetas de mi ordenador existe un error de excepción con color azul. Cuando se apaga y se enciende el ordenador el solo, me sale una pantalla parecida al juego de los barquitos muy curiosa."
Traducción: "Windowes peta y sale un pantallazo. Se reinicia y hace un scandisk de superficie".
 
Con el rollo de hacerlo fácil, lo que se está consiguiendo es que el usuario se crea que las cosas funcionan de una manera totalmente diferente a como lo hacen. Un poco de educación joer, luego te encuentras ficheros de güord donde el nombre es casi tan largo como el mismo documento. De coña eh?. Yo he visto esto:
 
DOCUMENTO PARA MARÍA SOBRE LAS GALLETAS QUE EL OTRO DIA ME MANDO Y ESTABAN CADUCADAS POR TRES MESES.doc

???? A ver hombre, el nombre de un fichero debe ser indicativo sobre su contenido, pero, no me jodas, y pongas de nombre el contenido del fichero. Los espacios en los nombres de ficheros son el peor invento que he visto. Dan un güevo de problemas en todos los S.O. (SISI en güindous tb).

'Bug' es una palabra inglesa que literalmente significa 'Bicho'.

Si tienes hormigas en tu casa son 'bugs', como también lo son las cucarachas. Si las rocias con pesticida estás haciendo un 'Debug'.

En programación el problema no es mucho más grave que las hormigas que corren por casa. Quizá sean molestas. Quizá se deba perder tiempo en eliminarlos. Pero todo el mundo sabe que si tienes una casa, es normal que entren 'bugs'.
Los 'bugs' en informática, a diferencia de las hormigas, se de deben a la negligencia del programador (a menos que el programador deje migas de pan - puede que para saber volver a casa-). Estos personajes no se preocupan por contemplar todos los casos posibles para una situación dada. Más bien escriben una primera aproximación, realizan una prueva y si no falla (por eso solo se hace 1 prueba - a más pruebas más posibilidades de fallo -), aceptan el código por bueno. De esta manera pueden conectarse largas horas a 'BarraPunto' o 'SlashDot'. Dependiendo de si eres un 'extrangero' o un 'Americano'. No entra dentro de las pretensiones de este texto el explicar la diferencia entre 'extrangero' y 'Americano'. Los interesados en el tema pueden recurrir a cualquier documental made in HollyWood.

Así que una vez el software está ejecutandose en casa del usuario todavía no estamos ante una versión terminada. Aunque esta no es una característica que se suela nombrar en los contratos de software o 'EULA' en Microsoftniense.
Así que tras trabajar muchos años como programador es fácil acostumbrarse a que los usuarios lo llamen a uno para comunicarle que el programa no funciona.
Y como somos unas personas muy espléndidas les ofrecemos a nuestros usuarios algo de cultura en agradecimiento por su llamada. Les indicamos que no se trata de que el programa no funcione, sino que han encontrado un 'bug'.
Así que no tienen de que preocuparse. Hacemos un 'debug' del programa, les enviamos un 'parche' y todo el asunto solucionado.
En estos momentos, los menos entendidos, os podeis preguntar que es un 'parche'. Un 'parche', 'Service Pack' en Microsoftniense, es una unidad de código capaz de eliminar 'bugs' por si misma.
Estos 'parches' no dejan de ser programas, de tal manera que pueden contener nuevos errores e incluso necesitar 'parches'. En informática a este fenómeno se le conoce como recursividad.

Tras muchos y muchos años de 'parches' aparecen las 'versiones'. Una 'versión' es un programa que viene junto con todos los 'parches' creados hasta su fecha de nacimiento.
Así que con esta explicación llegamos a día de hoy. Y nos encontramos con Unix, un sistema operativo (Sistema:Conjunto de reglas, principios o medidas, enlazados entre sí. Operativo:Que funciona o es válido para algo ) que tiene muchas 'versiones' y pero que aún así sigue teniendo 'bugs'.
Así que extrapolando de los datos obtenidos jamás dejaran de haber 'bugs'. Haciendo realidad la frase "Lo único que sobrevive a una explosión nuclear son los 'bugs'"
Así que en lugar de quejarse, cada cual debe coger su propio mata-insectos y dedicarse a 'debuggear' su propia casa.

Si lees esta línea es que te has saltado todo el texto para ver el final.

Una cosa es lo que UNIX permita y otra cosa es hacer las cosas portables. Algo que me sorprendió de Windows 95 en su día es que pasó del formato 8.3 a llamar al directorio donde se instalaban los programas "Archivos de Programa". Muy bonito, pero lo cierto es que más de una vez los programas fallan debido a esto (el mismo photoshop 5 a veces). Ya se que UNIX permite espacios, pero también se que llamar a un directorio "/Partición 1" me va a dar problemas. Aunque programe mis scripts de forma portable, delimitando con comillas o escapando los espacios (/Partición\ uno) se que un script que tenga por ahi que alguien haya hecho a toda prisa no funcionará, o incluso causará destrozos. Para eso está el caracter de subrayado.
Ya se que puedo crear un archivo llamado "-R", o incluso "*", pero pensad en el usuario que luego tenga que borrarlo. "rm -R"? "rm *"?. Por supuesto hay maneras, pero no es plan de complicarse.

"lo que se está consiguiendo es que el usuario se crea que las cosas funcionan de una manera totalmente diferente a como lo hacen"
Personalmente no se como funcionan (a parte de los conocimientos básicos):
Mi televisor [Pulso botones y salen imagenes].
El autobús [Me monto y hace brum brum y corre].
Mi cerebro [Suena a hueco, así que no puede ser muy complicado, pero aún así no se como funciona].

Los sitemas operativos fueron creados para ocultar al usuario el hardware.
Si no fuera por ese objetivo tan loable continuaríamos programando todo en ensamblador.
O quizá incluso con lógica cableada.

"lo que se está consiguiendo es que el usuario se crea que las cosas funcionan de una manera totalmente diferente a como lo hacen"
Personalmente no se como funcionan (a parte de los conocimientos básicos):
Mi televisor [Pulso botones y salen imagenes].
El autobús [Me monto y hace brum brum y corre].
Mi cerebro [Suena a hueco, así que no puede ser muy complicado, pero aún así no se como funciona].

Los sitemas operativos fueron creados para ocultar al usuario el hardware.
Si no fuera por ese objetivo tan loable continuaríamos programando todo en ensamblador.
O quizá incluso con lógica cableada.

"Los espacios en los nombres de ficheros son el peor invento que he visto"
¿No entiendo porqué?
¿Dan problemas? Pues se solucionan.
A mis variables las llamo ContadorDeNumerosImpares y cosas así. PeroNoEsComoEscriboHabitualmente,PorqueSeríaUnPoco Engorroso¿NoCreesTú?

Los sitemas operativos fueron creados para ocultar al usuario el hardware. No, fueron creados para oculterle a los programas el hardware, asi cuando copio un fichero de un sitio a otro, al programa le da igual si es un disco duro, diskette, internet, etc..
Si ocultara el hardware al usuario, no sabriamos donde esta el ordenador por que el SO nos lo ha ocultado,
O quizá incluso con lógica cableada.
Mas bien con abaco

En programación el problema no es mucho más grave que las hormigas que corren por casa. Quizá sean molestas. Quizá se deba perder tiempo en eliminarlos.
Depende de la hormiga, no es lo mismo una hormiguita que un hormigon armado, intenta exterminar a este ultimo...

"Fueron creados para oculterle a los programas el hardware."
Cierto cierto, es que llevo toda la semana haciendo como que trabajo y eso cansa mucho. :(

Pero el argumento sigue siendo válido. ¿No?

Novatada de laboratorio de programación:

Hay un cachondo mental ( a falta de buscar el epíteto adecuado ) que se dedica a buscar ordenadores con cuentas de alumnos abiertas.
Simplemente hace "touch -- '-rf *'" en el $HOME del pardillo, y espera a que éste lo intente borrar....

Para acabar con el hormigon armado tengo un amigo mío, un tal Ibán, que no tiene problemas ni con hormigón armado, ni con acero, ni con nada.
Edificios más altos han caido, ¿o quizá no? :O

Los ordenadores no hacen magia. Tu tele, por ejemplo, sabes de sobra que si no sale nada, probablemente se te ha olvidado conectar la antena.

El autobús, sabes que si no se para donde te quieres bajar, es que probablemente no has pulsado el botón de parada.

Los S.O. fueren creados para proporcionar una interfaz entre las aplicacionmes y el hardware. No para ocultar nada. lo que psa es que el usuario normal ni siquiera sabe que es un S.O.

¿Tu crees que es lógico que un fichero tenga un nombre de 128 carácteres?

¿Es lógico que en un programa llames a una variable: char Estoesunavariable_tipo_char_que sirve_para llevar_un_contador_auxiliar?

NO, no es lógico, sobre todo si vas a utilizar esa variable 500 veces.

Cuando llamas a un amigo, le dices: Hola Francisco Fernández López o le dices: Hola Paco

Si para conducir hace falta el carné, para usar el vídeo te lees el manual antes, pues para el ordenador lo mismo...aprende a utilizarlo con corrección.

Y SI, los nombres con espacios son un coñazo, o nuncas has instalado un aplicación en archiv~1. (¿es eso intuitivo?) porque no pillaba "Archivos de programa".Se supone que esos nombre tienen que ser una referencia. NO una descripción.

Que el fin de semana empezó ayer para algunos.
 

"NO, no es lógico, sobre todo si vas a utilizar esa variable 500 veces"
He usado nombres de variables como nMaxNumVerticesPosibles y más lasgar aún. Y eso que cada vez tengo que escribirlas, cosa que no pasa con los nombres de archivo.

"Archivos de programa".Se supone que esos nombre tienen que ser una referencia. NO una descripción"
los inodos o nodos índice consisten de entre 64 y 200 bytes (depende del sistema UNIX) y es la plataforma del sistema de archivos de UNIX , los inodos funcionan como apuntadores (o punteros) a los datos físicos.
Si realmente se tratara de referencias usaríamos el número de inodo.
Claramente el nombre de archivo ha de ser descriptivo.
Yo a un archivo puedo llamarle: "Lista Asistentes 10-Enero.txt", ¿como debería de llamarlo? ¿"00321" quizá?

He usado nombres de variables como nMaxNumVerticesPosibles y más lasgar aún. Y eso que cada vez tengo que escribirlas, cosa que no pasa con los nombres de archivo.
 

Masoca

Yo a un archivo puedo llamarle: "Lista Asistentes 10-Enero.txt", ¿como debería de llamarlo? ¿"00321" quizá?
 
lista_asistentes_10_ene.txt está bien

Pero que "anti-güindous" que sois

Ya van dos virus por correo esta mañana, powered by MS-Outlook.

"lista_asistentes_10_ene.txt está bien"
Pues sí.
Pero entonces debería de ser más facil escribir el caracter _ ([Shift]+[-]).

O quizá mejor aún, substituir el carácter [Espacio] por el [_] para la línea de comandos.
Ej:
cp_Mi archivo de texto.txt_Mi copia del archivo de texto
Pero aún así [_] debería de ser más fácil de escribir, porque es un caracter algo incómodo para intercalarlo cada 8-10 carácteres.

Los SO fueron creados para ocultarle a los programas el hardware.

El Güindous (e.d. el concepto de "escritorio") fue creado para introducir "un ordenador en cada hogar".

El problema es que se dejó la idea de "hardware" por el camino.

Con el rollo de Intenne tienes disponible a un monto de gente que hagas esas pruebas gratis

char cadena[256];

main() {
    azar_ascii64(cadena,255);
    mkdir(cadena); /* -> asi no puedo hacer rm -f * */
    mkdir("\e"); /* se escapa de las manos */
}

---
¡ Ahora vas y lo cascas !

Sobre este tema también nos hablaron en Fallo en MacOSX que no pudimos editar en su día por no haber enlaces donde verificar la información.

La historia la publique en mbp el 9 de noviembre, dos dias antes que la mencionada, bajo el título La irresponsabilidad de los programadores, ante éste titulo y conociendo a los usuarios de barrapunto mejor no editar, pues vale copio el comentario de la historia para los que no van a pinchar el enlace:

Leo en la sección de En Bruto, distintas historias de pobrecitos habladores exijiendo un colegio que les defienda. ¿ Y quién nos defiende de ellos?. En El Mundo podemos leer como cientos de usuarios de Mac, que se bajaron el programa iTunes de reproducción de música, perdieron todos sus archivos y particiones por un error de programación, más concretamente por una coma puesta al final de una orden que debia borrar la versión anterior de iTunes y con esa coma borró todos los archivos del disco duro de los usuarios. Por supuesto nadie paga, las licencias protegen a los programadores y a sus empresas, ¿ quien defiende al usuario?

La historia llevaba sus correspondientes enlaces para verificar todo lo verificable.

Saludos

 

Muy bueno el texto, y completamente de acuerdo.

Si lees esta línea es que te has saltado todo el texto para ver el final.

Lo interesante suele estar al final ¿o no?

Saludos
   

He usado nombres de variables como nMaxNumVerticesPosibles y más lasgar aún. Y eso que cada vez tengo que escribirlas, cosa que no pasa con los nombres de archivo.

>>Masoca

Pues yo diría que los que no usan nombres largos son unos vagos. Luego coges un programa de los susodichos y no hay quien lo entienda. Te encuentras por ejemplo con líneas como:


ne=na+ni*no+2003;
ni=na*4;
no=nu+2000;

Yo a un archivo puedo llamarle: "Lista Asistentes 10-Enero.txt", ¿como debería de llamarlo? ¿"00321" quizá?
 
>>lista_asistentes_10_ene.txt está bien

Pues no, no está bien, porque no sigues un convenio. Lo lógico sería que pusieras el año, porque si no llegará el año que viene y ya no vale. Y mejor usar algo tal que así para si en algún momento se quiere automatizar algo o hacer una búsqueda:

10-01-2001:lista_asistentes.txt

     

Pero el problema no es de Unix, es decir del kernel, el problema es del shell, que no puede referenciar ciertos caracteres en nombres de ficheros (recuerda que es un programa de usuario), es decir, sin tener en cuenta el shell, desde otros programas (podría ser un shell con otro enfoque o cualquier otra cosa) se pueden manejar perfectamente ficheros con todos esos caracteres excepcionales.

La cuestión es, ¿se debe diseñar el modelo de nombres del sistema de ficheros en función de un solo programa de usuario, en este caso el shell?

Vale vale.

10-01-2001:lista_asistentes.txt

Pero a ver.... asistentes A DONDE!? XDD

??????????
No te entiendo. A ver si me lo explicas.

Hay un librito excelente llamado "La practica de la programacion", de Kernighan y Pike ( traducido al español )

Dice don Diómidis:

The most common dangerous constructs that can appear in step 1 are variable
references (e.g. $PATH, $word) and commands inside backquotes (e.g. `find
. -type f -name 'ch2.*'`). These dangerous constructs are quite common,
appearing among other places in the original article describing the Bourne
shell [6] (for i in * do if test -d $d/$i [...]), in other scripts in the
reference of the original example [5 p. 141, 143], and even in quite recent
work by the same authors [7, p. 149].
[...]
[5] Brian W. Kernighan and Rob Pike. The UNIX Programming Environment.
Prentice-Hall, 1984.
[7] Brian W. Kernighan and Rob Pike. The Practice of Programming.
Addison-Wesley, 1999

Y se supone que estos son los expertos.

Si ocultara el hardware al usuario, no sabriamos donde esta el ordenador por que el SO nos lo ha ocultado,

Ojalá. Es lo que en el MIT llaman "ubiquitous computing" o algo así.

David Moon:

The root cause and the real source of the risk here is the attempt to use an interactive command language as a programming language. It's evidently a very seductive temptation, since the mistake has been repeated many times by many people, but in the end that approach just can't work. A programming language needs a syntax and semantics that don't confuse the data being processed with the program doing the processing.

Bueno verás. Si pongo un comentario por defecto me pone 2 puntos a no ser que le dé a una casillita que pone 'Sin Puntos +1 Bonus'.

A veces la selecciono, a veces no (dependiendo del tiempo que le eche a la respuestas), por ejemplo, ahora mismo no la voy a seleccionar.

Así que, las quejas, a Barrapunto. Yo no hice el sistema, sólo me muevo en él, y me la trae floja que me den o no me den puntos de karma por mis comentarios.
 

Buenas, un comentario más a vueeeeltas con el Karma.

Reconozoco que al principio yo también estaba mosqueado con esas "moderaciones" hasta que casualmente encontré la siguiente discusión. Tampoco sabía lo de esa cajita "Sin +1 Bonus"; nunca te acostarás sin saber una cosa más :)

De todas formas, pienso que ni la FAQ (creo que ahora son sólo 3 los puntos de moderación) ni desde luego la información acerca de los MiBarrapunto estan muy actualizadas. En el caso de los MiBarrapunto, casi tienes que descubrirlo por el método de prueba y error; claro que siempre queda el conocido RTFS ;)

Una FAQ más completa evitaría estas discusiones, que lo único que provocan es una pérdida de tiempo (yo ya pierdo demasiado con éste mensaje). Afortunadamente (o desgraciadamente) esto no es como Slashdot, en donde las noticias con cientos de comentarios son la norma; plantas un treshold de -1 y tan campante. Y acerca del Karma, RMFSignature (aunque suelo cambiarla a menudo).