Pregunta

Tengo una secuencia de comandos Perl que se ejecuta en un cuadro de AIX.

La secuencia de comandos intenta abrir un archivo desde un directorio determinado y no puede leer el archivo porque el archivo no tiene permiso de lectura, pero aparece un error diferente al decir ioctl para dispositivo .

¿No debería decir algo así como sin permisos de lectura para archivo o algo similar?

¿Qué significa este mensaje ioctl for device inapropiado?

¿Cómo puedo solucionarlo?

EDITAR: Esto es lo que encontré cuando hice strace .

open("/local/logs/xxx/xxxxServer.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 
    0666) = 4 _llseek(4, 0, [77146], SEEK_END) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffc14f8) = -1 ENOTTY 
    (Inappropriate ioctl for  device)
¿Fue útil?

Solución

Lo más probable es que signifique que el abierto no falló .

Cuando Perl abre un archivo, comprueba si el archivo es un TTY (para que pueda responder al operador de prueba de código -T $ fh ) emitiendo el TCGETS ioctl contra eso. Si el archivo es un archivo normal y no un tty, el ioctl falla y establece errno en ENOTTY (valor de cadena: " ioctl inadecuado para el dispositivo "). Como dice ysth, la razón más común para ver un valor inesperado en $! es verificarlo cuando no es válido, es decir, en cualquier parte otro que inmediatamente después de que fallara una llamada al sistema. , por lo que es sumamente importante probar los códigos de resultados de sus operaciones.

Si open en realidad te devolvió el valor falso, y encontraste a ENOTTY en $! , entonces consideraría esto un pequeño error (dando un valor inútil de $! ) pero también sería muy curioso en cuanto a cómo sucedió. El código y / o la salida de truss serían ingeniosos.

Otros consejos

Errores impares como " ioctl inadecuado para el dispositivo " Por lo general son el resultado de revisar $! en otro punto que no sea justo después de que una llamada al sistema haya fallado. Si mostraras tu código, apuesto a que alguien rápidamente señalará tu error.

" archivos " Los sistemas de tipo * nix son en gran medida un concepto abstracto.

Pueden ser áreas del disco organizadas por un sistema de archivos, pero también pueden ser una conexión de red, un poco de memoria compartida, la salida del búfer de otro proceso, una pantalla o un teclado.

Para que Perl sea realmente útil, refleja este modelo muy de cerca y no trata los archivos emulando una cinta magnética como hacen muchos 4gls.

Así que intentó un " IOCTL " la operación 'abrir para escribir' en un identificador de archivo que no permite operaciones de escritura que es una operación IOCTL inapropiada para ese dispositivo / archivo.

Lo más fácil de hacer es pegar un " o die 'No se puede abrir la declaración $ myfile' al final de tu apertura y puedes elegir tu propio mensaje significativo.

" ioctl inadecuado para dispositivo " es la cadena de error para el error ENOTTY. Solía ??activarse principalmente mediante intentos de configurar las propiedades del terminal (por ejemplo, el modo eco) en un descriptor de archivo que no era terminal (pero, por ejemplo, un archivo normal), por lo tanto, ENOTTY. Más generalmente, se activa cuando se realiza un ioctl en un dispositivo que no es compatible con ese ioctl, de ahí la cadena de error.

Para averiguar qué ioctl se está haciendo que falla, y en qué descriptor de archivo, ejecute el script bajo strace / truss. Reconocerá ENOTTY, seguido de la impresión real del mensaje de error. Luego, averigüe qué número de archivo se usó y qué llamada open () devolvió ese número de archivo.

Acabo de arreglar este error de Perl. Consulte https://rt.perl.org/Ticket/Display.html?id= 124232

Cuando empujamos la capa de búfer a PerlIO y hacemos una comprobación isatty () que falla que obviamente falla en todos los archivos normales, ignora el error errno ENOTTY.

Momento Eureka!

He tenido este error antes.

¿Invocó al depurador de Perl con algo como: -

perl -d yourprog.pl > log.txt

Si es así, ¿qué está pasando? Perl Debug intenta consultar y quizás restablecer el ancho del terminal. Cuando stdout no es un terminal, esto falla con el mensaje IOCTL.

La alternativa sería que tu sesión de depuración se cuelgue para siempre porque no viste el mensaje para obtener instrucciones.

Dado que este es un error fatal y también bastante difícil de depurar, tal vez la solución se pueda ubicar en algún lugar (en la línea de comandos provista?):

export GPG_TTY=$(tty)

De: https://github.com/keybase/keybase-issues/issues / 2798

Encontré este error hoy al intentar usar el código para eliminar una carpeta / archivos que viven en una caja de Windoze 7 que está montada como un recurso compartido en un servidor Centos. Obtuve el icotl inadecuado para el error del dispositivo y probé todo lo que me vino a la mente. Lea casi todas las publicaciones en la red relacionadas con esto.

Obviamente, el problema se aisló en el recurso compartido Windoze montado en el servidor Linux. Mirado en los permisos de archivo en el cuadro de Windoze y anotó que los archivos tenían sus permisos configurados para solo lectura.

Cambié esos, volví al servidor Linux y todo funcionó como se esperaba. Puede que esta no sea la solución para la mayoría pero, con suerte, le ahorra a alguien algo de tiempo.

Probé el siguiente código que parecía funcionar:

if(open(my $FILE, "<File.txt")) {
    while(<$FILE>){
    print "

Probé el siguiente código que parecía funcionar:

<*>";} } else { print "File could not be opened or did not exists\n"; }
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top