OK, haha seems like I am talking to myself. It seems that if you launch
the voice over utility you can mute and disable speech and then it
creates a plist file in the home folder under ~/Library/Preferences and
in that plist there are some data entries like this
I am assuming I can modify this in WGM (or casper 7) and disable it
Kids are doing the same funny thing? I'm a 24 year old sys admin and I still find it hilarious sometimes 🙂 Especially when I ssh into colleagues machines, turn the volume up with `osascript -e 'set volume 7'` and then say something to them.
Is that something we're supposed to grow out of?
On Mar 31, 2010, at 12:07 PM, Thomas Larkin wrote:
So it seems that you can mute all sounds and voices in the voice over utility application. So I just need to figure out how to script it, or better yet modify it with MCX
yes, kids are still doing the same old funny things. I guess dirty jokes told from the computer never gets old
I find it hilarious as well, but teachers apparently do not, and when
someone calls my boss and my boss says we'll do it, I gotta do it. It
works on my machines but I shared the hint with other people and they
claim it does not work...which is weird.
If anyone wants to give it a try on their machine and let me know if it
does or doesn't work that would be great. You can respond to me off of
list too so we don't spam the list.
Try piping something like a man page into say in a shell. Then your colleagues might learn something too!!! Pick a long one like egrep 🙂
Seriously though, will the managed preference stop it working through the shell? Do you allow the students to set their own shell environments. You could edit .tchsrc .cshrc or whichever with an alias on the say command
alias say 'echo $USER has been monitored for using this command'
alias say 'osacsript -e "set volume 0"'
and make the file(s) read only to them. Of course they can learn to unalias, but at least it means that the default will be for say to not work.
I guess you could alias unalias!
Better still though, would be to edit the sudoers file so that users couldn't run the say command (I've never needed to do this, but this should work)
user ALL=(ALL) NOPASSWD: !/usr/bin/say
Possibly worth setting something like this, before they have learned how to do it. If you have never edited the sudoers file, use visudo. It locks the file and will do grammar checking.
The global extension I disabled only disables it outside of text
editors. I found this out later on. It will disable it in web browsers
and so forth. However, if you say open Textwranger and highlight some
text and try to do text to speech it works, but out side a text editor
it doesn't. I am still playing with the settings.
It also seems to not disable it in email clients either. So it looks
like it only disables it on the web browsers. As far as I can tell, it
will not disable say commands from the shell.
Well, it's 7 years after the original post, so I have to ask: Has this been resolved?
Silly computer hilarity aside, we are now testing with MacBook Airs. We don't want the kiddos, who are taking a reading test, to select the text, hit option-s, then have the paragraph read to them aloud. That kind of defeats the purpose of the test.