Also, how many ports are enumerated here?
The output won't necessarily reflect physical parallel ports of course (but also useful to compare against the dmesg output).

I followed your sugestions but I don´t get any hint on how to advance on this.
Outputs nothing

ls -l /proc/sys/dev/
outputs 4 directories: cdrom, parport, raid, scsi
ls -l /proc/sys/dev/parport
outputs:
-r--r--r-- 1 root root 0 Jan 15 08:23 autoprobe
-r--r--r-- 1 root root 0 Jan 15 08:23 autoprobe0
-r--r--r-- 1 root root 0 Jan 15 08:23 autoprobe1
-r--r--r-- 1 root root 0 Jan 15 08:23 autoprobe2
-r--r--r-- 1 root root 0 Jan 15 08:23 autoprobe3
dr-xr-xr-x 1 root root 0 Jan 15 08:23 devices
-r--r--r-- 1 root root 0 Jan 15 08:23 dma
-r--r--r-- 1 root root 0 Jan 15 08:23 irq
-r--r--r-- 1 root root 0 Jan 15 08:23 modes
-rw-r--r-- 1 root root 0 Jan 15 08:23 spintime

If I cat any of the autoprobe* files, I get nothing.

outputs
-bash: sudo: command not found

[
Outputs
-bash: lpinfo: command not found

Honestly, I thought this was going to be much more easy. Although before posting I read a lot of documentation and forums, I expected something like " change permissions on file x" or " make sure your xxxx device is listed under xxxx". I appreciate all your help, guys, but maybe is time to leave this behind and admit that the industrial program running in tty1 somehow is hijacking the printing capability of the system as some of you suggested before.
Anyhow, if someone can point out a reading on how the basic printing works inside the O.S. ( without cups or lprng), will be good to learn.

I was specifically answering your question literally about how to go about investigating the presence/status of a parallel port, and some possible indication that a printer might be attached. Such ports are legacy hardware ports, with little complexity when compared to USB technology. Since dmesg returns nothing about the existence of a parallel port, I can only speculate about how the legacy printing application is able to communicate with the printer via a parallel port interface. Perhaps it is loading a driver when first launched?

You could check if the parport_pc, ppdev, and/or lp driver are loaded...
I didn't expect that command to be present, since a previous post confirmed no 'lp' or 'lpr' command available. You need to have CUPS installed or lprng installed.

Is there a chance that the Linux machine is using a parallel port configured with a different base to the default 0x378. Perhaps worth checking the BIOS to see if the parallel port is known and its base address displayed configured as expected.

https://www.computerhope.com/issues/ch000042.htm
https://www.kernel.org/doc/html/v4.1...e/parport.html

Solved !!!
Following Ferrari indications I checked the Bios configuration. LPT1 was configured as "Device Mode : ECP and EPP 1.9 mode". I changed it to "Normal" and now it prints from both the industrial program and from the Linux tty.
Why the industrial program was able to print with that Bios configuration? No idea.
Thank you very much for all the indications.

I'm glad to read of your success here (with changing the port mode). This can also be done when loading the parport_pc driver. The application may have been able to set this on the fly perhaps.