send(3pm)

💌 send(3pm) — the Tk::send era 💌

okay bestie, welcome to Tk::send, straight outta the User Contributed Perl Documentation section of the send(3pm) manual. yes this is a real page, yes it's giving "walkie-talkie but for apps", and yes you're gonna understand it by the end, i promise 🫶

---

✨ NAME ✨

Tk::send — Execute a command in a different application

like, literally yell a command at some other app and make it do stuff. remote control energy 👑

---

🎀 SYNOPSIS 🎀

$result = $widget->send(?options,?app=>cmd?arg arg ...?)

look at her. iconic. slightly cursed question marks. we love her 💖

---

🌸 DESCRIPTION 🌸

so here's the vibe: this method arranges for cmd (plus whatever args you brought along) to be 'sent' to the application named by app. it hands you back the result, or an error. and because errors are a thing that exist, bestie, you should probably 'wrap' that whole call in eval{} and test $@. no cap, just do it.

and app? it can be the name of any application whose main window is on the display containing the sender's main window. it does not need to be within the same process. across the room, across the process table, doesn't matter, she's connected 💅

now, about the args:

• if no arg arguments are present, then the string to be sent is contained entirely within the cmd argument.
• if one or more args are present, they get concatenated, separated by white space, to form the string to be sent.

if the initial arguments of the call begin with -, they get treated as options. here's what's currently defined:

• -async — Requests asynchronous invocation. in this case the send command completes immediately without waiting for cmd to complete in the target application. no result will be available, and errors in the sent command will be ignored. (if the target application is in the same process as the sending application, then the -async option is ignored. rude but true.)
• -- — Serves no purpose except to terminate the list of options. this one's only needed if app could contain a leading - character. it's a little bouncer at the door of your option list, that's the whole job 🚪

---

🦋 APPLICATION NAMES 🦋

the name of an application is set initially from the name of the program or script that created the application. you can query and change the name of an application with the appname method. cute, right? rename your app like you rename your spotify playlists ✨

---

🌈 WHAT IS A SEND 🌈

okay so this is the lore section, sit down 🍓

the send mechanism was designed to allow Tcl/Tk applications to send Tcl Scripts to each other. this does not map very well onto perl/Tk. like, the vibes do not transfer, bestie.

here's what actually happens: Perl/Tk "sends" a string to app, and what happens as a result of this depends on the receiving application.

• if the other application is a Tcl/Tk4.* application, it will be treated as a Tcl Script.
• if the "other" application is a perl/Tk application (including sends to self), then the string is passed as an argument to a method call of the following form:

$mainwindow->Receive(string);

there's a default (AutoLoaded) Tk::Receive which returns an error to the sending application. a particular application may define its own Receive method in any class in MainWindow's inheritance tree to do whatever it sees fit. for example, it could eval the string, possibly in a Safe "compartment". main character choices only 💜

and the reverse direction? if a Tcl/Tk application "sends" anything to a perl/Tk application, then the perl/Tk application would have to attempt to interpret the incoming string as a Tcl Script. simple cases should not be too hard to emulate: split on white space and treat the first element as the "command" and the other elements as arguments. boom, homemade Tcl interpreter, sort of 🙈

---

🔥 SECURITY 🔥

bestie. this is the part where i need you to lock in. no scrolling past this one. 💀

the send command is potentially a serious security loophole, since any application that can connect to your X server can send scripts to your applications. hence the default behaviour outlined above. (with the availability of Safe it may make sense to relax default behaviour a little.)

unmonitored eval'ing of these incoming "scripts" can cause perl to read and write files and invoke subprocesses under your name. that's your name, your files, your whole situation. not it 😭

host-based access control such as that provided by xhost is particularly insecure, since:

• it allows anyone with an account on particular hosts to connect to your server
• and if disabled, it allows anyone anywhere to connect to your server

in order to provide at least a small amount of security, core Tk checks the access control being used by the server and rejects incoming sends unless both:

1. (a) xhost-style access control is enabled (i.e. only certain hosts can establish connections), and
2. (b) the list of enabled hosts is empty.

this means that applications cannot connect to your server unless they use some other form of authorization such as that provided by xauth. so like, use xauth, okay? for me? 🫶

---

👑 SEE ALSO 👑

"eval" in perlfunc, Safe, system's administrator/corporate security guidelines etc.

(the "etc." is doing a lot of heavy lifting there but we respect it 💅)

---

⭐ KEYWORDS ⭐

application, name, remote execution, security, send

---

and that's the whole page, bestie!! this lil gem lives in perl v5.40.1, dated 2025-04-13, page send(3pm). go forth and send responsibly, mwah 💖🎀🦋