Linux背景刷卡器
我目前有一个连接到嵌入式 Linux 机器的 USB 卡刷卡器，据我所知和我的研究，它充当键盘，输入所有数据，就像我正在打字一样。现在我有一个 perl 脚本，它可以获取所有这些数据并将其保存到文件中。唯一的问题是，它只知道当perl脚本在前台运行时获取数据，否则“键盘”输入到哪里。
我的问题是如何让这张卡刷卡在每次读取输入时运行脚本？或者我可以通过在后台运行的应用程序以某种方式捕获数据吗？ IE 在 C++ 程序中，在后台运行，cin 会读取机器的任何输入吗？
我从来没有摆弄过刷卡器，所以我不能 100% 确定它们是如何工作的。
任何对此的建议将不胜感激！
I currently have a USB card swipe attached to an embedded linux machine and from what I can tell and from what I have researched it acts as a keyboard, and inputs all the data as if I were typing. Now I have a perl script that takes all this data and saves it to a file. The only problem is, it only knows to take the data when the perl script is running in the foreground otherwise, where does the "keyboard" input to.
My question is how can I make this card swipe run the script every time it reads input? Or could I somehow capture the data with an app running in the background. I.E. in a c++ program, running in the background, will cin read ANY input to the machine?
I have never messed around with a card swipe reader so Im not 100% sure on how they work.
Any suggestions on this would be appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我几乎完全做到了这一点（除了显示为键盘的 USB 条形码阅读器）。
我的系统具有自定义 USB 热插拔规则，可在插入 USB 设备时根据其供应商和产品 ID 对其进行检测。此规则创建到
/dev/input/中相应event设备的符号链接。然后我就有了一个始终运行的 C 守护进程。它监视
/dev/input/目录，当它看到符号链接出现时，它会打开event设备。然后，它使用EVIOCGRABIOCTL 来获取专用的事件设备（这可以防止数据在其他应用程序中显示为键盘输入），并读取与按键对应的输入事件。该守护进程将按键转换为字符并将其存储在数据库中。I have done almost exactly this (except with a USB barcode reader that appeared as a keyboard).
My system has custom USB hotplug rule that detects the USB device when it is plugged in based on its vendor and product ID. This rule creates a symlink to the corresponding
eventdevice in/dev/input/.I then have a C daemon that runs at all times. It watches the
/dev/input/directory, and when it sees the symlink appear it opens theeventdevice. It then uses theEVIOCGRABIOCTL to grab the event device for exclusive use (this prevents the data appearing as keyboard input in other applications), and reads input events corresponding to keypresses. The daemon converts the keypresses into characters and stores them in a database.我有一个想法，但它很笼统。
您是否可以持续监视另一个程序中的数据，对其进行缓冲，然后在缓冲区达到一定大小或在一段时间内没有活动时将结果通过管道传输到 Perl 脚本中？如果您将其通过管道输入，则不必修改 Perl 脚本，因为它仍然位于 STDIN 上。
那么，就会是这样的：
监控程序->收集数据->将其通过管道传输到您的 Perl 程序中
我希望这个想法有帮助。
-布莱恩·J·斯蒂纳尔-
I have an idea, but it is very general.
Can you constantly be monitoring for data in another program, buffer it, and then pipe the results into your perl script when the buffer reaches a certain size or goes for a certain period of time without activity? If you pipe it in, you shouldn't have to modify your perl script, since it will still be on STDIN.
So, it would be like this:
Monitoring Program -> Collects Data -> Pipes it into your Perl program
I hope this idea is helpful.
-Brian J. Stinar-
cin 将从连接的终端输入设备读取输入。在不了解更多关于软件设计的情况下，我的第一感觉是从 Perl 脚本读取数据并不是最佳的设计选择。正如您所描述的，我可以使用 Perl 脚本读取嵌入式 Linux 设备上的红外遥控器，但一般来说，我从主应用程序中直接与硬件或供应商提供的 API 进行交互。您的读卡器是否提供了 API？
当读卡器插入您的计算机时，读卡器的设备名称是什么（/dev/*）？我会打开它并以这种方式阅读。
cin will read input from the attached terminal input device. Without knowing more about your software design, my first hunch is reading the data from a Perl script isn't the best choice of design. I can read IR remotes on embedded Linux devices using a Perl script as you describe, but in general I interface directly with the hardware or a vendor supplied API from within my main application. Was there an API provided with your card reader?
What's the device name of the card reader when it's plugged into your machine (/dev/*)? I'd open that and read it that way.
我从来没有在 Linux 中处理过这个问题。然而，这听起来与我在 Windows 中看到的非常相似。
根据我的经验，许多此类设备都会被操作系统自动检测为键盘类型的设备。因此，来自阅读器的任何输入都会被输入到真实键盘使用的同一键盘流中。当任何实际程序运行时，我们无法区分读卡器输入数据和用户只是非常非常快地打字之间的区别。
因此，您会得到原始问题中描述的行为：读卡器的输入仅进入正常键盘输入所在的位置 - 进入焦点程序。
您最好的选择是调查制造商的网站（或以其他方式联系他们），并查明他们是否提供某种驱动程序，允许程序完全独立于键盘流捕获该输入。
如果制造商不提供这样的东西，也许某些第三方会提供。但不幸的是，我从未调查过这一点，所以我不知道该告诉你从哪里开始寻找。
I've never dealt with this in Linux. However this sounds very similar to what I've seen in Windows.
In my experience, a lot of these types of devices are automatically detected by the operating system as a keyboard-type of device. So any input from the reader is fed into the same keyboard stream that the real keyboard uses. By the time this reaches any actual programs running, there is no way to tell the difference between the card reader inputting data and a user just typing really really fast.
As a consequence, you get the behavior described in the original question: the card reader's input only goes where normal keyboard input goes - to the program in focus.
Your best option would be to investigate the manufacturer's website (or otherwise contact them) and find out if they provide some kind of driver that would allow a program to catch that input totally separately from the keyboard stream.
If the manufacturer doesn't provide such a thing, perhaps some 3rd-party does. But unfortunately, I've never investigated that so I don't know where to tell you to even start looking.