System Beep?

Steve Gronicus at SGA.Ninja
Fri Mar 8 17:03:50 EST 2019


I tried all three, nothing audio.  I am beginning to wonder if something I the operating system is at fault.
The three lines do produce symbols.  The first two are a rectangle with a space in the middle and the last one spelled out "bel" in short/small characters.




--------------------------------------------------------------------------------------------
There's 99 bugs in the code, in the code.
99 bugs in the code.
Take one down and patch it all around.
Now there's 117 bugs in the code.

-----Original Message-----
From: Python-list <python-list-bounces+gronicus=sga.ninja at python.org> On Behalf Of DL Neil
Sent: Friday, March 8, 2019 3:51 PM
To: python-list at python.org
Subject: Re: System Beep?

Dear Squeak, sorry, Dear Steve,

Back in the ?good, old days when we used to walk alongside a mainframe CPU whilst it cogitated, we would often use the BEL character to alert us to job completion (and meantime bunk-off to go have a coffee, cakes,
...) - more seriously, it alerted telegraph and telex operators to an incoming message (you can still hear similar "beeps" on some emergency-worker radio systems, NASA moon mission video-replays, etc).

In the grips of nostalgia, I tried to make it work using the REPL, and failed, but first...


On 9/03/19 7:13 AM, Steve wrote:
> How can I cause a system beep using code?
> This is using the computer's internal speaker, not an audio external
> speaker.
> Do I have control of duration or volume?

The BEL character was included in the ASCII standard as chr(7)*. Back in 
those days, the rest of the world didn't exist - the "A" stands for 
"American". Accordingly, the huge advance was that we would be allowed 
to use lower-case letters, instead of all-caps (capital letters). Using 
French accents or German umlauts (etc), anything beyond the "standard" 
26-letters of "the" alphabet, would have been infra-dig to a well 
brought-up, clean-cut, American boy ("truth, justice, and the American 
way"*) - excepting that he wouldn't have understood the term, because 
didn't know of any other language than English. This problem was 
acknowledged and solved with Unicode. Viva Python 3!

Before you laugh, perhaps in disbelief that at one time computers ran 
exclusively in upper-case, take a closer look at ASCII, because even 
then there was no "$" or "£", only a generic currency symbol, "¤". What 
were they thinking? Simple: computers worked with numbers - why 
clutter-up the place by adding pesky letters, labelling 'answers', and 
stuff like that?

Whilst we have protocols or understandings in Python, eg a file simply 
ends, there is no need for any special indication or code; back in those 
?good, old days there were a number of different ways to encode 
characters AND to indicate other features of a file. Accordingly, the 
"II" part of ASCII - Information Interchange.

So, it was not merely a character set in terms of an alphabet, but by 
standardising some universal 'understandings' made "interchange" 
possible between computer systems (without which the Internet would 
never have become a possibility!). We knew these non-alpha components as 
"control characters". They still exist in various forms today - I was 
helping a Network Tech revise for his exams, and we ran through the 
exchanges necessary to establish a computer on a network using DHCP, and 
instead of "right" or "correct" I joked with him by saying "ACK" (and 
later, when he made a mistake "NAK") which really made him blink!

The really 'fun' ones today (because there is a difference between Linux 
and MS-Windows, ie we've lost the "standard") are "carriage return" (the 
process of pushing a typewriter's "carriage" (roller holding the paper) 
from the (right-hand!) end of one line all the way to the left again), 
"line feed" which was the second half of the typewriter process, when 
you first pulled the big handle at the top-right of the machine, it 
rolled the paper upward (normally) one line - sometimes called "New 
line". Thus "CR", "LF", and often "CRLF", and "NL". (why have two codes 
to perform what is (now!) one action?)

"BEL" is one of those "control characters".

If you are familiar with Python's chr() and ord(), you will remember 
that characters can be represented both as strings and as integers (in 
the case of ASCII, one character occupied one byte; but now that Python 
3 uses Unicode, the one-to-one is no longer necessarily true). Thus 
control characters can be expressed in either representation*. In the 
case of BEL, my elephantine memory immediately recalled it as 7! As if 
that wasn't enough, Python also has its set of string literals and 
escape characters*.

Just for fun, I started playing in the Python shell. I couldn't persuade 
v3.6 to ring my bell (sob, sob). Searching revealed discussion of "\A" 
and of an official Unicode character, but despite the "you got mail" 
message ringing in my ears, I couldn't bell the cat* (er, python)

 >>> print( chr( 7 ) )

 >>> print ('\a')

 >>> print( u"\u2407" )

[in each case, the blank line of 'output' and end="\n" default-action 
should have followed the bell ringing/beeping, but didn't]

Does it work for you?


* web-refs:
https://en.wikipedia.org/wiki/Bell_character
https://docs.python.org/3.6/reference/lexical_analysis.html#literals
https://linuxconfig.org/list-of-python-escape-sequence-characters-with-examples

in case you program in multiple languages:
https://rosettacode.org/wiki/Terminal_control/Ringing_the_terminal_bell

being supercilious:
https://www.outsidethebeltway.com/superman_truth_justice_and_all_that_stuff/
https://en.wikipedia.org/wiki/Belling_the_Cat
[this guy is an ancestor - does that perhaps explain why I answer 
questions on this list?]

-- 
Regards =dn
-- 
https://mail.python.org/mailman/listinfo/python-list




More information about the Python-list mailing list