Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^11: Querying program port

by marto (Archbishop)
on Aug 12, 2019 at 12:31 UTC ( #11104328=note: print w/replies, xml ) Need Help??

in reply to Re^10: Querying program port
in thread Querying program port

bad interpreter: No such file or directory.

Had you searched for this you'd have found out that you've got a carriage return on the end of the shebang line. dos2unix will help.

Replies are listed 'Best First'.
Re^12: Querying program port
by Marshall (Abbot) on Aug 13, 2019 at 15:01 UTC
    I've used Unix systems where CR on the shebang line is not a problem. So I guess this is Unix variant or local installation option specific. A bigger annoyance to me was that LPR interpreted the CR as an extra LF so any printout of my Windows code had blank lines interspersed. I am no longer am working in that mixed environment, but I had a simple s/\s*$//; print "$_\n"; at each end to correct any weirdness encountered although Windows appears to be very well behaved with just <LF> endings.

    Perhaps as interesting sidenote, the network standard is CR/LF. So all TCP lines end that way whether generated on Unix or Windows. Perl takes care of the details for you. So on Unix if you print to the printer, \n means just LF while when printing to a TCP socket \n means CR/LF.

    Your Newline link was hoot! A trip down memory lane. The ASR 33 teletype was the first computer terminal I ever used. Not mentioned in the Wiki is that the standard way to end a line was: CR/LF/Rubout(NULL). Dr. StrangeLove has an ASR 33 teletype in it. When you hit a rubout, the carriage that does the printing, bobs up and down. Tapes would start with a sequence of rubouts and end with a series of rubouts. This has a distinctive sound to it. The rubout or NULL caused all 8 columns on the tape to be punched. This was a reliability issue. The paper tape was soaked with oil. Inserting a NULL every line caused all 8 pins to be exercised (and hence lubricated) on read or write.

    Update: For fun, I was able to find some ASR33 documentation online at: ASR33. The Wiki describes a scenario where a certain sequence of characters could cause the terminal to misprint (a printing character sent too soon after a CR). I don't remember anything like that. I figure this part of the Wiki is highly suspect! Folks should understand that this was way before the age of microprocessors and we are talking about an extremely "stupid" machine. Each key press resulted in one mechanical action on the terminal. I suspect that this thing was too "stupid" to see a single character and then perform a sequence of mechanical actions (couldn't do CR and LF at the same time even if it wanted to). There was RS-232 hardware flow control via the hardware lines with names like RTS (Request to Send)/CTS(Clear to Send) etc. So there was a way for the terminal to signal that it wasn't ready to accept the next character until it was ready. Times have certainly changed! Nowadays, there is often either software flow control (XON/XOFF) or none at all. The assumption in the latter case is that you can receive my max length request packet at full speed. And implicit is that I can receive your max length response packet at full speed. This requires "smarts" and buffers - neither was available in the ASR33 days.

Re^12: Querying program port
by CougarXR7 (Acolyte) on Aug 12, 2019 at 14:24 UTC
    Thank you for helping!
    Please read my previous reply to poj.
    Also what is, "shebang line"?

      I've already replied to that post. Shebang_(Unix), web searches are wonderful these days ;).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11104328]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2019-10-17 01:19 GMT
Find Nodes?
    Voting Booth?