mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
47caad3f8f
64
README.md
64
README.md
@ -87,44 +87,44 @@ LCTT 的组成
|
||||
|
||||
LCTT 现由项目管理委员会（PMC）进行管理，成员如下：
|
||||
|
||||
- 组长 @wxy （主席）
|
||||
- 选题 @oska874
|
||||
- 选题 @lujun9972
|
||||
- 技术 @bestony
|
||||
- 校对 @pityonline
|
||||
- 译者 @geekpi
|
||||
- 译者 @qhwdw
|
||||
- 🎩 主席 @wxy
|
||||
- 🎩 选题 @oska874
|
||||
- 🎩 选题 @lujun9972
|
||||
- 🎩 技术 @bestony
|
||||
- 🎩 校对 @pityonline
|
||||
- 🎩 译者 @geekpi
|
||||
- 🎩 译者 @qhwdw
|
||||
|
||||
目前 LCTT 核心成员有：
|
||||
|
||||
- 核心成员 @vizv
|
||||
- 核心成员 @zpl1025
|
||||
- 核心成员 @runningwater
|
||||
- 核心成员 @FSSlc
|
||||
- 核心成员 @Vic020
|
||||
- 核心成员 @alim0x
|
||||
- 核心成员 @martin2011qi
|
||||
- 核心成员 @Locez
|
||||
- 核心成员 @ucasFL
|
||||
- 核心成员 @MjSeven
|
||||
- ❤️ 核心成员 @vizv
|
||||
- ❤️ 核心成员 @zpl1025
|
||||
- ❤️ 核心成员 @runningwater
|
||||
- ❤️ 核心成员 @FSSlc
|
||||
- ❤️ 核心成员 @Vic020
|
||||
- ❤️ 核心成员 @alim0x
|
||||
- ❤️ 核心成员 @martin2011qi
|
||||
- ❤️ 核心成员 @Locez
|
||||
- ❤️ 核心成员 @ucasFL
|
||||
- ❤️ 核心成员 @MjSeven
|
||||
|
||||
曾经做出了巨大贡献的核心成员，被列入荣誉榜：
|
||||
|
||||
- 前任选题 @DeadFire
|
||||
- 前任校对 @reinoir222
|
||||
- 前任校对 @PurlingNayuki
|
||||
- 前任校对 @carolinewuyan
|
||||
- 功勋成员 @tinyeyeser
|
||||
- 功勋成员 @vito-L
|
||||
- 功勋成员 @willqian
|
||||
- 功勋成员 @GOLinux
|
||||
- 功勋成员 @bazz2
|
||||
- 功勋成员 @ictlyh
|
||||
- 功勋成员 @jasminepeng
|
||||
- 功勋成员 @dongfengweixiao
|
||||
- 功勋成员 @strugglingyouth
|
||||
- 功勋成员 @GHLandy
|
||||
- 功勋成员 @rusking
|
||||
- 🏆 前任选题 @DeadFire
|
||||
- 🏆 前任校对 @reinoir222
|
||||
- 🏆 前任校对 @PurlingNayuki
|
||||
- 🏆 前任校对 @carolinewuyan
|
||||
- 🏆 前任校对 @jasminepeng
|
||||
- 🏆 功勋成员 @tinyeyeser
|
||||
- 🏆 功勋成员 @vito-L
|
||||
- 🏆 功勋成员 @willqian
|
||||
- 🏆 功勋成员 @GOLinux
|
||||
- 🏆 功勋成员 @bazz2
|
||||
- 🏆 功勋成员 @ictlyh
|
||||
- 🏆 功勋成员 @dongfengweixiao
|
||||
- 🏆 功勋成员 @strugglingyouth
|
||||
- 🏆 功勋成员 @GHLandy
|
||||
- 🏆 功勋成员 @rusking
|
||||
|
||||
全部成员列表请参见： https://linux.cn/lctt-list/ 。
|
||||
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
translating by Flowsnow
|
||||
|
||||
Create a containerized machine learning model
|
||||
======
|
||||
|
||||
|
||||
@ -1,229 +0,0 @@
|
||||
Translating by qhwdw
|
||||
An introduction to Udev: The Linux subsystem for managing device events
|
||||
======
|
||||
Create a script that triggers your computer to do a specific action when a specific device is plugged in.
|
||||
|
||||
|
||||
Udev is the Linux subsystem that supplies your computer with device events. In plain English, that means it's the code that detects when you have things plugged into your computer, like a network card, external hard drives (including USB thumb drives), mouses, keyboards, joysticks and gamepads, DVD-ROM drives, and so on. That makes it a potentially useful utility, and it's well-enough exposed that a standard user can manually script it to do things like performing certain tasks when a certain hard drive is plugged in.
|
||||
|
||||
This article teaches you how to create a [udev][1] script triggered by some udev event, such as plugging in a specific thumb drive. Once you understand the process for working with udev, you can use it to do all manner of things, like loading a specific driver when a gamepad is attached, or performing an automatic backup when you attach your backup drive.
|
||||
|
||||
### A basic script
|
||||
|
||||
The best way to work with udev is in small chunks. Don't write the entire script upfront, but instead start with something that simply confirms that udev triggers some custom event.
|
||||
|
||||
Depending on your goal for your script, you can't guarantee you will ever see the results of a script with your own eyes, so make sure your script logs that it was successfully triggered. The usual place for log files is in the **/var** directory, but that's mostly the root user's domain. For testing, use **/tmp** , which is accessible by normal users and usually gets cleaned out with a reboot.
|
||||
|
||||
Open your favorite text editor and enter this simple script:
|
||||
|
||||
```
|
||||
#!/usr/bin/bash
|
||||
|
||||
echo $date > /tmp/udev.log
|
||||
```
|
||||
|
||||
Place this in **/usr/local/bin** or some such place in the default executable path. Call it **trigger.sh** and, of course, make it executable with **chmod +x**.
|
||||
|
||||
```
|
||||
$ sudo mv trigger.sh /usr/local/bin
|
||||
$ sudo chmod +x /usr/local/bin/trigger.sh
|
||||
```
|
||||
|
||||
This script has nothing to do with udev. When it executes, the script places a timestamp in the file **/tmp/udev.log**. Test the script yourself:
|
||||
|
||||
```
|
||||
$ /usr/local/bin/trigger.sh
|
||||
$ cat /tmp/udev.log
|
||||
Tue Oct 31 01:05:28 NZDT 2035
|
||||
```
|
||||
|
||||
The next step is to make udev trigger the script.
|
||||
|
||||
### Unique device identification
|
||||
|
||||
In order for your script to be triggered by a device event, udev must know under what conditions it should call the script. In real life, you can identify a thumb drive by its color, the manufacturer, and the fact that you just plugged it into your computer. Your computer, however, needs a different set of criteria.
|
||||
|
||||
Udev identifies devices by serial numbers, manufacturers, and even vendor ID and product ID numbers. Since this is early in your udev script's lifespan, be as broad, non-specific, and all-inclusive as possible. In other words, you want first to catch nearly any valid udev event to trigger your script.
|
||||
|
||||
With the **udevadm monitor** command, you can tap into udev in real time and see what it sees when you plug in different devices. Become root and try it.
|
||||
|
||||
```
|
||||
$ su
|
||||
# udevadm monitor
|
||||
```
|
||||
|
||||
The monitor function prints received events for:
|
||||
|
||||
* UDEV: the event udev sends out after rule processing
|
||||
* KERNEL: the kernel uevent
|
||||
|
||||
|
||||
|
||||
With **udevadm monitor** running, plug in a thumb drive and watch as all kinds of information is spewed out onto your screen. Notice that the type of event is an **ADD** event. That's a good way to identify what type of event you want.
|
||||
|
||||
The **udevadm monitor** command provides a lot of good info, but you can see it with prettier formatting with the command **udevadm info** , assuming you know where your thumb drive is currently located in your **/dev** tree. If not, unplug and plug your thumb drive back in, then immediately issue this command:
|
||||
|
||||
```
|
||||
$ su -c 'dmesg | tail | fgrep -i sd*'
|
||||
```
|
||||
|
||||
If that command returned **sdb: sdb1** , for instance, you know the kernel has assigned your thumb drive the **sdb** label.
|
||||
|
||||
Alternately, you can use the **lsblk** command to see all drives attached to your system, including their sizes and partitions.
|
||||
|
||||
Now that you have established where your drive is located in your filesystem, you can view udev information about that device with this command:
|
||||
|
||||
```
|
||||
# udevadm info -a -n /dev/sdb | less
|
||||
```
|
||||
|
||||
This returns a lot of information. Focus on the first block of info for now.
|
||||
|
||||
Your job is to pick out parts of udev's report about a device that are most unique to that device, then tell udev to trigger your script when those unique attributes are detected.
|
||||
|
||||
The **udevadm info** process reports on a device (specified by the device path), then "walks" up the chain of parent devices. For every device found, it prints all possible attributes using a key-value format. You can compose a rule to match according to the attributes of a device plus attributes from one single parent device.
|
||||
|
||||
```
|
||||
looking at device '/devices/000:000/blah/blah//block/sdb':
|
||||
KERNEL=="sdb"
|
||||
SUBSYSTEM=="block"
|
||||
DRIVER==""
|
||||
ATTR{ro}=="0"
|
||||
ATTR{size}=="125722368"
|
||||
ATTR{stat}==" 2765 1537 5393"
|
||||
ATTR{range}=="16"
|
||||
ATTR{discard\_alignment}=="0"
|
||||
ATTR{removable}=="1"
|
||||
ATTR{blah}=="blah"
|
||||
```
|
||||
|
||||
A udev rule must contain one attribute from one single parent device.
|
||||
|
||||
Parent attributes are things that describe a device from the most basic level, such as it's something that has been plugged into a physical port or it is something with a size or this is a removable device.
|
||||
|
||||
Since the KERNEL label of **sdb** can change depending upon how many other drives were plugged in before you plugged that thumb drive in, that's not the optimal parent attribute for a udev rule. However, it works for a proof of concept, so you could use it. An even better candidate is the SUBSYSTEM attribute, which identifies that this is a "block" system device (which is why the **lsblk** command lists the device).
|
||||
|
||||
Open a file called **80-local.rules** in **/etc/udev/rules.d** and enter this code:
|
||||
|
||||
```
|
||||
SUBSYSTEM=="block", ACTION=="add", RUN+="/usr/local/bin/trigger.sh"
|
||||
```
|
||||
|
||||
Save the file, unplug your test thumb drive, and reboot.
|
||||
|
||||
Wait, reboot on a Linux machine?
|
||||
|
||||
Theoretically, you can just issue **udevadm control --reload** , which should load all rules, but at this stage in the game, it's best to eliminate all variables. Udev is complex enough, and you don't want to be lying in bed all night wondering if that rule didn't work because of a syntax error or if you just should have rebooted. So reboot regardless of what your POSIX pride tells you.
|
||||
|
||||
When your system is back online, switch to a text console (with Ctl+Alt+F3 or similar) and plug in your thumb drive. If you are running a recent kernel, you will probably see a bunch of output in your console when you plug in the drive. If you see an error message such as Could not execute /usr/local/bin/trigger.sh, you probably forgot to make the script executable. Otherwise, hopefully all you see is a device was plugged in, it got some kind of kernel device assignment, and so on.
|
||||
|
||||
Now, the moment of truth:
|
||||
|
||||
```
|
||||
$ cat /tmp/udev.log
|
||||
Tue Oct 31 01:35:28 NZDT 2035
|
||||
```
|
||||
|
||||
If you see a very recent date and time returned from **/tmp/udev.log** , udev has successfully triggered your script.
|
||||
|
||||
### Refining the rule into something useful
|
||||
|
||||
The problem with this rule is that it's very generic. Plugging in a mouse, a thumb drive, or someone else's thumb drive will indiscriminately trigger your script. Now is the time to start focusing on the exact thumb drive you want to trigger your script.
|
||||
|
||||
One way to do this is with the vendor ID and product ID. To get these numbers, you can use the **lsusb** command.
|
||||
|
||||
```
|
||||
$ lsusb
|
||||
Bus 001 Device 002: ID 8087:0024 Slacker Corp. Hub
|
||||
Bus 002 Device 002: ID 8087:0024 Slacker Corp. Hub
|
||||
Bus 003 Device 005: ID 03f0:3307 TyCoon Corp.
|
||||
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 hub
|
||||
Bus 001 Device 003: ID 13d3:5165 SBo Networks
|
||||
```
|
||||
|
||||
In this example, the **03f0:3307** before **TyCoon Corp.** denotes the idVendor and idProduct attributes. You can also see these numbers in the output of **udevadm info -a -n /dev/sdb | grep vendor** , but I find the output of **lsusb** a little easier on the eyes.
|
||||
|
||||
You can now include these attributes in your rule.
|
||||
|
||||
```
|
||||
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/thumb.sh"
|
||||
```
|
||||
|
||||
Test this (yes, you should still reboot, just to make sure you're getting fresh reactions from udev), and it should work the same as before, only now if you plug in, say, a thumb drive manufactured by a different company (therefore with a different idVendor) or a mouse or a printer, the script won't be triggered.
|
||||
|
||||
Keep adding new attributes to further focus in on that one unique thumb drive you want to trigger your script. Using **udevadm info -a -n /dev/sdb** , you can find out things like the vendor name, sometimes a serial number, or the product name, and so on.
|
||||
|
||||
For your own sanity, be sure to add only one new attribute at a time. Most mistakes I have made (and have seen other people online make) is to throw a bunch of attributes into their udev rule and wonder why the thing no longer works. Testing attributes one by one is the safest way to ensure udev can identify your device successfully.
|
||||
|
||||
### Security
|
||||
|
||||
This brings up the security concerns of writing udev rules to automatically do something when a drive is plugged in. On my machines, I don't even have auto-mount turned on, and yet this article proposes scripts and rules that execute commands just by having something plugged in.
|
||||
|
||||
Two things to bear in mind here.
|
||||
|
||||
1. Focus your udev rules once you have them working so they trigger scripts only when you really want them to. Executing a script that blindly copies data to or from your computer is a bad idea in case anyone who happens to be carrying the same brand of thumb drive plugs it into your box.
|
||||
2. Do not write your udev rule and scripts and forget about them. I know which computers have my udev rules on them, and those boxes are most often my personal computers, not the ones I take around to conferences or have in my office at work. The more "social" a computer is, the less likely it is to get a udev rule on it that could potentially result in my data ending up on someone else's device or someone else's data or malware on my device.
|
||||
|
||||
|
||||
|
||||
In other words, as with so much of the power provided by a GNU system, it is your job to be mindful of how you are wielding that power. If you abuse it or fail to treat it with respect, it very well could go horribly wrong.
|
||||
|
||||
### Udev in the real world
|
||||
|
||||
Now that you can confirm that your script is triggered by udev, you can turn your attention to the function of the script. Right now, it is useless, doing nothing more than logging the fact that it has been executed.
|
||||
|
||||
I use udev to trigger [automated backups][2] of my thumb drives. The idea is that the master copies of my active documents are on my thumb drive (since it goes everywhere I go and could be worked on at any moment), and those master documents get backed up to my computer each time I plug the drive into that machine. In other words, my computer is the backup drive and my production data is mobile. The source code is available, so feel free to look at the code of attachup for further examples of constraining your udev tests.
|
||||
|
||||
Since that's what I use udev for the most, it's the example I'll use here, but udev can grab lots of other things, like gamepads (this is useful on systems that aren't set to load the xboxdrv module when a gamepad is attached) and cameras and microphones (useful to set inputs when a specific mic is attached), so realize that it's good for a lot more than this one example.
|
||||
|
||||
A simple version of my backup system is a two-command process:
|
||||
|
||||
```
|
||||
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", SYMLINK+="safety%n"
|
||||
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/trigger.sh"
|
||||
```
|
||||
|
||||
The first line detects my thumb drive with the attributes already discussed, then assigns the thumb drive a symlink within the device tree. The symlink it assigns is **safety%n**. The **%n** is a udev macro that resolves to whatever number the kernel gives to the device, such as sdb1, sdb2, sdb3, and so on. So **%n** would be the 1 or the 2 or the 3.
|
||||
|
||||
This creates a symlink in the dev tree, so it does not interfere with the normal process of plugging in a device. This means that if you use a desktop environment that likes to auto-mount devices, you won't be causing problems for it.
|
||||
|
||||
The second line runs the script.
|
||||
|
||||
My backup script looks like this:
|
||||
|
||||
```
|
||||
#!/usr/bin/bash
|
||||
|
||||
mount /dev/safety1 /mnt/hd
|
||||
sleep 2
|
||||
rsync -az /mnt/hd/ /home/seth/backups/ && umount /dev/safety1
|
||||
```
|
||||
|
||||
The script uses the symlink, which avoids the possibility of udev naming the drive something unexpected (for instance, if I have a thumb drive called DISK plugged into my computer already, and I plug in my other thumb drive also called DISK, the second one will be labeled DISK_, which would foil my script). It mounts **safety1** (the first partition of the drive) at my preferred mount point of **/mnt/hd**.
|
||||
|
||||
Once safely mounted, it uses [rsync][3] to back up the drive to my backup folder (my actual script uses rdiff-backup, and yours can use whatever automated backup solution you prefer).
|
||||
|
||||
### Udev is your dev
|
||||
|
||||
Udev is a very flexible system and enables you to define rules and functions in ways that few other systems dare provide users. Learn it and use it, and enjoy the power of POSIX.
|
||||
|
||||
This article builds on content from the [Slackermedia Handbook][4], which is licensed under the [GNU Free Documentation License 1.3][5].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/11/udev
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://linux.die.net/man/8/udev
|
||||
[2]: https://gitlab.com/slackermedia/attachup
|
||||
[3]: https://opensource.com/article/17/1/rsync-backup-linux
|
||||
[4]: http://slackermedia.info/handbook/doku.php?id=backup
|
||||
[5]: http://www.gnu.org/licenses/fdl-1.3.html
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (SMPlayer in Linux: Features, Download and Installation)
|
||||
|
||||
@ -1,344 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (HankChow)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (Some Alternatives To ‘top’ Command line Utility You Might Want To Know)
|
||||
[#]: via: (https://www.ostechnix.com/some-alternatives-to-top-command-line-utility-you-might-want-to-know/)
|
||||
[#]: author: (SK https://www.ostechnix.com/author/sk/)
|
||||
[#]: url: ( )
|
||||
|
||||
Some Alternatives To ‘top’ Command line Utility You Might Want To Know
|
||||
======
|
||||
|
||||
|
||||
|
||||
Every now and then, I see a lot of open source programs, tools, and utilities are being added to GitHub and GitLab by developers across the world. Some of those programs are new and some of them are just alternative programs to the most popular and widely used existing Linux programs. In this tutorial, we are going to discuss about some good alternatives to [**‘top’**][1], the command line task manager program. Read on.
|
||||
|
||||
### Alternatives To ‘top’ Command line Utility
|
||||
|
||||
As of writing this guide, I am aware of the following 6 alternatives to Top program, namely:
|
||||
|
||||
1. Htop
|
||||
2. Vtop
|
||||
3. Gtop
|
||||
4. Gotop
|
||||
5. Ptop
|
||||
6. Hegemon
|
||||
|
||||
|
||||
|
||||
I will keep updating this list if I come across any similar utilities in the days to come. Bookmark this guide if you’re interested to know about such utilities.
|
||||
|
||||
#### 1\. Htop
|
||||
|
||||
The **htop** is a popular, open source and cross-platform interactive process manager. It is my favorite system activity monitor tool. htop is an enhanced version of the classic top program. It is originally developed for Linux, but the developer extended its support to other Unix-like operating systems such as FreeBSD and Mac OS X. htop is free open source, and ncurses-based utility released under GPLv2.
|
||||
|
||||
Compared to the classic top command, it has the following few advantages.
|
||||
|
||||
* htop starts faster than top program.
|
||||
* htop allows us to scroll horizontally and vertically to view all processes and full command lines.
|
||||
* There is no need to type the PID to kill a process in htop. But in top, you need to type the PID to kill the process.
|
||||
* There is no need to type PID to change the priority of a process, but in top command, you do.
|
||||
* We can kill multiple processes at once in htop.
|
||||
* In top program you are subject to a delay for each unassigned key you press. It is especially annoying when multi-key escape sequences are triggered by accident.
|
||||
|
||||
|
||||
|
||||
**Installing htop**
|
||||
|
||||
htop is available in the default repositories of most Linux distributions.
|
||||
|
||||
On Arch-based systems, run the following command to install htop.
|
||||
|
||||
```
|
||||
$ sudo pacman -S htop
|
||||
```
|
||||
|
||||
On Debian-based systems:
|
||||
|
||||
```
|
||||
$ sudo apt install htop
|
||||
```
|
||||
|
||||
On RPM-based systems:
|
||||
|
||||
```
|
||||
$ sudo dnf install htop
|
||||
```
|
||||
|
||||
Or,
|
||||
|
||||
```
|
||||
$ sudo yum install htop
|
||||
```
|
||||
|
||||
On openSUSE:
|
||||
|
||||
```
|
||||
$ sudo zypper in htop
|
||||
```
|
||||
|
||||
**Usage**
|
||||
|
||||
When you htop command without any arguments, you will see the following screen.
|
||||
|
||||
```
|
||||
$ htop
|
||||
```
|
||||
|
||||
|
||||
As you can see, htop task manager shows total memory and swap usage, total number of tasks, system average load and system uptime on the top. On the bottom side, just like top command, it displays the list of processes in multiple columns. Each column displays details such as pid, user, priority, nice value, virtual memory usage, cpu usage, memory usage by each process etc. You can read about these parameters in the top command tutorial linked in the first paragraph.
|
||||
|
||||
Unlike top command, htop allows you to perform each operation with a dedicated function key. Here is the list of shortcut keys to interact with htop.
|
||||
|
||||
* **F1, h, ?** – Open help section.
|
||||
* **F2, S(Shift+s)** – Go to the setup section, where you can configure the meters displayed at the top of the screen, set various display options, choose among color schemes, and select which columns are displayed, in which order etc.
|
||||
* **F3, /** – Search the command lines of all the displayed processes.
|
||||
* **F4, \** – Filter processes. Just type the part of the process name and you will see only the processes that matches the name. Press F4 again and hit ESC key to cancel filtering.
|
||||
* **F5, t** – Switch between tree view and default view. Press + to view the sub-tree.
|
||||
* **F6, <, >** – Sort the processes by PID, USER, PRIORITY, NICE value, CPU usage, MEMORY usage etc.
|
||||
* **F7, ]** – Increase the selected process’s priority.
|
||||
* **F8, [** – Decrease the selected process’s priority.
|
||||
* **F9, k** – Kill the processes. Use the UP/DOWN arrows to choose the process and press F9 or k to kill it.
|
||||
* **F10, q** – Exit htop.
|
||||
|
||||
|
||||
|
||||
All shortcuts keys are given at the bottom of the htop interface.
|
||||
|
||||
Please note that some of these function keys might be assigned to various Terminal operations. For example, when I hit the F2 key, it didn’t go to htop setup section. Instead it displayed the option to set the title to my Terminal window. In such cases, you might need to other keys given along with the function keys.
|
||||
|
||||
Apart from the above mentioned keys, there are few more keys available to perform different functions. For example,
|
||||
|
||||
* Press **‘u’** to show processes owned by a user.
|
||||
* **Shift+m** will sort the processes by memory usage.
|
||||
* **Shift+p** – Sort the processes by processor usage.
|
||||
* **Shit+t** – Sort the processes by time.
|
||||
* **CTRL+l** – Refresh screen.
|
||||
|
||||
|
||||
|
||||
htop can do everything using the shortcut keys without having to mention any options when launching it. However, you can use some flags when starting it.
|
||||
|
||||
For example, to start htop displaying only processes owned by given user, run:
|
||||
|
||||
```
|
||||
$ htop -u <username>
|
||||
```
|
||||
|
||||
Change the Output Refresh Interval:
|
||||
|
||||
```
|
||||
$ htop -d 10
|
||||
```
|
||||
|
||||
As you can see, htop usage is incredibly easier than the usage of top command.
|
||||
|
||||
Refer htop man pages to know more about the available options and functionalities.
|
||||
|
||||
```
|
||||
$ man htop
|
||||
```
|
||||
|
||||
Also, refer the project home page and HitHub repository.
|
||||
|
||||
+ [htop website](http://hisham.hm/htop/)
|
||||
+ [htop GitHub Repository](https://github.com/hishamhm/htop)
|
||||
|
||||
#### 2\. Vtop
|
||||
|
||||
**Vtop** is yet another alternative to good-old top utility. It is a free and open source, command-line system activity monitor written in **NodeJS** and released under MIT. It uses unicode braille characters to draw CPU and Memory charts, helping you to visualize spikes.
|
||||
|
||||
Make sure you have NodeJS installed on your system. If not installed yet, refer the following guide.
|
||||
|
||||
Once node installed, run the following command to install Vtop.
|
||||
|
||||
```
|
||||
$ npm install -g vtop
|
||||
```
|
||||
|
||||
After installing Vtop, simply run vtop to start monitoring.
|
||||
|
||||
```
|
||||
$ vtop
|
||||
```
|
||||
|
||||
Sample output:
|
||||
|
||||
![][3]
|
||||
|
||||
As you can see, Vtop interface is little bit different than top and htop programs. It displays each details in a separate box layout. You will see all shortcuts keys to interact with Vtop at the bottom.
|
||||
|
||||
Here is the list of shortcuts:
|
||||
|
||||
* **dd** – Kill the processes.
|
||||
* **UP** arrow or **k** – Move up.
|
||||
* **DOWN** arrow or **j** – Move down.
|
||||
* **Left** arrow or or **h** to – Zoom the graphs in.
|
||||
* **Right** arrow or **l** – Zoom the graphs out.
|
||||
* **g** – Jump to top of the process list.
|
||||
* **SHIFT+g** – Jump to end of the process list.
|
||||
* **c** – Sort processes by CPU usage.
|
||||
* **m** – Sort processes by memory usage.
|
||||
|
||||
|
||||
|
||||
For more details, refer the following Vtop resources.
|
||||
|
||||
+ [Vtop website](http://parall.ax/vtop)
|
||||
+ [Vtop GitHub Repository](https://github.com/MrRio/vtop)
|
||||
|
||||
|
||||
#### 3\. Gtop
|
||||
|
||||
Gtop is same as Vtop system activity monitor. It is also written in NodeJS and released under MIT license.
|
||||
|
||||
To install it, run:
|
||||
|
||||
```
|
||||
$ npm install gtop -g
|
||||
```
|
||||
|
||||
Start gtop using command:
|
||||
|
||||
```
|
||||
$ gtop
|
||||
```
|
||||
|
||||
Sample output:
|
||||
|
||||
|
||||
|
||||
I noticed Gtop interface is very nice. It showed each elements with different set of colors which is eye-pleasing.
|
||||
|
||||
Keyboard shortcuts:
|
||||
|
||||
* **p** – Sort processes by process Id.
|
||||
* **c** – Sort processes by CPU usage.
|
||||
* **m** – Sort processes by Memory usage.
|
||||
* **q** or **ctrl+c** – Quit Gtop.
|
||||
|
||||
|
||||
|
||||
For more details, visit Gtop GitHub page.
|
||||
|
||||
+ [Gtop GitHub Repository](https://github.com/aksakalli/gtop)
|
||||
|
||||
|
||||
#### 4\. Gotop
|
||||
|
||||
As the name says, **Gotop** is a TUI graphical activity monitor, written in **Go** programming language. It is completely free, open source and inspired by **gtop** and **vtop** programs which we mentioned in the previous sections. We already have written about it a while ago. If you’re interested to learn about it, please visit the following link.
|
||||
|
||||
+ [Gotop – Yet Another TUI Graphical Activity Monitor, Written In Go
|
||||
](https://www.ostechnix.com/manage-python-packages-using-pip/)
|
||||
|
||||
#### 5\. Ptop
|
||||
|
||||
Some of you might not like programs written in NodeJS and Go. If you’re one of them, there is another process monitor program named **Ptop** , which is written in **Python** programming language. It is free, open source system activity monitor, released under MIT license.
|
||||
|
||||
Ptop is compatible with both Python2.x and Python3.x, so you can easily install it using **Pip** , a package manager to install programs developed in Python. If you haven’t installed Pip yet, refer the following link.
|
||||
|
||||
+ [How To Manage Python Packages Using Pip](https://www.ostechnix.com/manage-python-packages-using-pip/)
|
||||
|
||||
After installing Pip, run the following command to install ptop.
|
||||
|
||||
```
|
||||
$ pip install ptop
|
||||
```
|
||||
|
||||
Or, you can compile from source as shown below.
|
||||
|
||||
```
|
||||
$ git clone https://github.com/darxtrix/ptop
|
||||
$ cd ptop/
|
||||
$ pip install -r requirements.txt # install requirements
|
||||
$ sudo python setup.py install
|
||||
```
|
||||
|
||||
To update Ptop, run:
|
||||
|
||||
```
|
||||
$ pip install --upgrade ptop
|
||||
```
|
||||
|
||||
Even if you don’t update, Ptop will prompt you if you’d like to update to the latest version when launch it for the first time.
|
||||
|
||||
Now, let us run ptop and see what happens.
|
||||
|
||||
```
|
||||
$ ptop
|
||||
```
|
||||
|
||||
Here you go!
|
||||
|
||||
Here is the list of shortcuts keys to interact with ptop:
|
||||
|
||||
* **Ctrl+k** – Kill the process.
|
||||
* **Ctrl+n** – Sort processes by memory usage.
|
||||
* **Ctrl+t** – Sort processes by process lifetime.
|
||||
* **Ctrl+r** – Reset the stats.
|
||||
* **Ctrl+f** – Filter a specific process information. Just type process name and you will see its details only.
|
||||
* **Ctrl+l** – View the information of a selected process.
|
||||
* **g** – Go to the top of the process list.
|
||||
* **Ctrl+q** – Quit Ptop.
|
||||
|
||||
|
||||
|
||||
Ptop has a feature to change the theme. If you want a pretty output of Ptop, you could use any one of the available themes. Currently the following themes are supported:
|
||||
|
||||
* colorful
|
||||
* elegant
|
||||
* simple
|
||||
* dark
|
||||
* light
|
||||
|
||||
|
||||
|
||||
To set a theme, for example colorful, simply run:
|
||||
|
||||
```
|
||||
$ ptop -t colorful
|
||||
```
|
||||
|
||||
To view help section, use **-h** :
|
||||
|
||||
```
|
||||
$ ptop -h
|
||||
```
|
||||
|
||||
For more details, refer the project’s GitHub page.
|
||||
|
||||
+ [Ptop Github Repository](https://github.com/darxtrix/ptop)
|
||||
|
||||
#### 6\. Hegemon
|
||||
|
||||
**Hegemon** is another system activity monitor application written in **Rust** programming language. If you’re fan of programs written in Rust, hegemon might be a good choice. We have published a brief review about Hegemon a while ago. Please visit the following link to know more about this tool.
|
||||
|
||||
[Hegemon – A Modular System Monitor Application Written In Rust](https://www.ostechnix.com/hegemon-a-modular-system-monitor-application-written-in-rust/)
|
||||
|
||||
### Conclusion
|
||||
|
||||
You know now six alternatives to Top program. I won’t claim these programs are better than or best replacement for ‘top’ program. But it is always nice to know some alternatives. I use htop mostly to monitor the processes. Now is your turn. Have you used any tools listed here? Great! Which is your favorite tool and why? Please share your experience in the comment section below.
|
||||
|
||||
More good stuffs to come. Stay tuned!
|
||||
|
||||
Cheers!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/some-alternatives-to-top-command-line-utility-you-might-want-to-know/
|
||||
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.ostechnix.com/author/sk/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.ostechnix.com/the-top-command-tutorial-with-examples-for-beginners/
|
||||
[2]: data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7
|
||||
[3]: http://www.ostechnix.com/wp-content/uploads/2018/11/vtop.png
|
||||
@ -1,71 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (Drive a locomotive through your Linux terminal)
|
||||
[#]: via: (https://opensource.com/article/18/12/linux-toy-sl)
|
||||
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
|
||||
[#]: url: ( )
|
||||
|
||||
Drive a locomotive through your Linux terminal
|
||||
======
|
||||
Using the sl command, you can train yourself to get on track with a fun command-line experience.
|
||||
|
||||
|
||||
It's December, and every Linux terminal user deserves a reward just for making through the year. So we're bringing you a sort of advent calendar of Linux command-line toys. What's a command-line toy? It might be a game, a pointless little time waster, or just something to bring you joy at the terminal.
|
||||
|
||||
**sl** , which is short for steam locomotive.
|
||||
|
||||
Today's Linux command-line toy is a suggestion from Opensource.com community moderator [Ben Cotton][1] . Ben suggested, which is short for steam locomotive.
|
||||
|
||||
It's also, conveniently and not coincidentally, a common typo for the Linux **ls** command. Want to stop mistyping ls? Try installing **sl**. It's probably packaged for your default repos. For me, in Fedora, that means it was as simple to install as:
|
||||
|
||||
```
|
||||
$ sudo dnf install sl -y
|
||||
```
|
||||
|
||||
Now, just type **sl** to try it out.
|
||||
|
||||
|
||||
|
||||
You may notice, as I did, that **Ctrl+C** doesn't derail your train, so you have to wait for the entire train to pass. That'll teach you to mistype **ls**!
|
||||
|
||||
Want to check out the source to **sl**? It's over [on GitHub][2].
|
||||
|
||||
**sl** is also a great opportunity to share a personal PSA about open source licensing. While its [license][3] was "open source enough" to be packaged for my distribution, it's not technically an [OSI-approved][4] license. After the copyright line, the license reads simply:
|
||||
|
||||
```
|
||||
Everyone is permitted to do anything on this program including copying,
|
||||
modifying, and improving, unless you try to pretend that you wrote it.
|
||||
i.e., the above copyright notice has to appear in all copies.
|
||||
THE AUTHOR DISCLAIMS ANY RESPONSIBILITY WITH REGARD TO THIS SOFTWARE.
|
||||
```
|
||||
|
||||
Unfortunately, when you chose a license that's not OSI-approved, you may accidentally be creating extra work for your users, as they must figure out whether your license will work for their situation. Do their corporate policies allow them to contribute? Can they even legally use the program? Does the license mesh with the license of another program they wish to integrate with it?
|
||||
|
||||
Unless you're a lawyer (and perhaps, even if you are), navigating the space of non-standard licenses can be tricky. So if you're still looking for a New Year's Resolution, why not resolve to choose only OSI-approved licenses for any new projects you start in 2019.
|
||||
|
||||
No disrespect to the creator, though. **sl** is still a great little command-line toy.
|
||||
|
||||
Do you have a favorite command-line toy that you think I ought to profile? The calendar for this series is mostly filled out but I've got a few spots left. Let me know in the comments below, and I'll check it out. If there's space, I'll try to include it. If not, but I get some good submissions, I'll do a round-up of honorable mentions at the end.
|
||||
|
||||
Check out yesterday's toy, [Box yourself in on the Linux command line][5], and check back tomorrow for another!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/linux-toy-sl
|
||||
|
||||
作者：[Jason Baker][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jason-baker
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/users/bcotton
|
||||
[2]: https://github.com/mtoyoda/sl
|
||||
[3]: https://github.com/mtoyoda/sl/blob/master/LICENSE
|
||||
[4]: https://opensource.org/licenses
|
||||
[5]: https://opensource.com/article/18/12/linux-toy-boxes
|
||||
@ -0,0 +1,228 @@
|
||||
Udev 入门：管理设备事件的 Linux 子系统
|
||||
======
|
||||
创建这样一个脚本，当指定的设备插入时触发你的计算机去做一个指定动作。
|
||||
|
||||
|
||||
Udev 是一个让你的计算机使用设备事件的 Linux 子系统。通俗来讲就是，当你的计算机上插入了像网卡、外置硬盘（包括 U 盘）、鼠标、键盘、游戏操纵杆和手柄、DVD-ROM 驱动器等等设备时，代码能够检测到它们。这样就能写出很多可能非常有用的实用程序，而它已经很好了，普通用户就可以写出脚本去做一些事情，比如当某个硬盘驱动器插入时，执行某个任务。
|
||||
|
||||
这篇文章教你去如何写一个由一些 udev 事件触发的 [udev][1] 脚本，比如插入了一个 U 盘。当你理解了 udev 的工作原理，你就可以用它去做各种事情，比如当一个游戏手柄连接后加载一个指定的驱动程序，或者当你用于备份的驱动器连接后，自动执行备份工作。
|
||||
|
||||
### 一个初级的脚本
|
||||
|
||||
使用 udev 的最佳方式是让它工作在一个小的代码块中。不要指望从一开始就写出完整的脚本，而是从最简单的确认 udev 触发了某些指定的事件开始。
|
||||
|
||||
对于你的脚本，依据你的目标，并不是在任何情况下都能保证你亲眼看到你的脚本运行结果的，因此需要在你的脚本日志中确认它成功触发了。而日志文件通常放在 **/var** 目录下，但那个目录通常是 root 用户的领地。对于测试目的，可以使用 **/tmp**，它可以被普通用户访问并且在重启动后就被清除了。
|
||||
|
||||
打开你喜欢的文本编辑器，然后输入下面的简单脚本：
|
||||
|
||||
```
|
||||
#!/usr/bin/bash
|
||||
|
||||
echo $date > /tmp/udev.log
|
||||
```
|
||||
|
||||
把这个脚本放在 **/usr/local/bin** 或缺省可运行路径的位置中。将它命名为 **trigger.sh**，并运行 **chmod +x** 授予可运行权限：
|
||||
|
||||
```
|
||||
$ sudo mv trigger.sh /usr/local/bin
|
||||
$ sudo chmod +x /usr/local/bin/trigger.sh
|
||||
```
|
||||
|
||||
udev 用这个脚本并不做任何事情。当它运行时，这个脚本将在文件 **/tmp/udev.log** 中放入当前的时间戳。你可以自己测试一下这个脚本：
|
||||
|
||||
```
|
||||
$ /usr/local/bin/trigger.sh
|
||||
$ cat /tmp/udev.log
|
||||
Tue Oct 31 01:05:28 NZDT 2035
|
||||
```
|
||||
|
||||
接下来让 udev 去触发这个脚本。
|
||||
|
||||
### 唯一设备识别
|
||||
|
||||
为了让你的脚本能够被一个设备事件触发，udev 必须要知道在什么情况下调用该脚本。在现实中，你可以通过它的颜色、制造商、以及插入到你的计算机这一事实来识别一个 U 盘。而你的计算机，它需要一系列不同的标准。
|
||||
|
||||
Udev 通过序列号、制造商、以及提供商 ID 和产品 ID 号来识别设备。由于现在你的 udev 脚本还处于它的生命周期的早期阶段，因此要尽可能地宽泛、非特定和全包括。换句话说就是，你希望首先去捕获尽可能多的有效 udev 事件来触发你的脚本。
|
||||
|
||||
使用 **udevadm monitor** 命令你可以实时利用 udev，并且可以看到当你插入不同设备时发生了什么。用 root 权限试一试。
|
||||
|
||||
```
|
||||
$ su
|
||||
# udevadm monitor
|
||||
```
|
||||
|
||||
监视函数输出接收到的事件：
|
||||
|
||||
* UDEV：在规则处理之后发出 udev 事件
|
||||
* KERNEL：内核发送 uevent 事件
|
||||
|
||||
|
||||
|
||||
在 **udevadm monitor** 命令运行时，插入一个 U 盘，你将看到各种信息在你的屏幕上滚动而出。注意那一个 **ADD** 事件的事件类型。这是你所需要的识别事件类型的一个好方法。
|
||||
|
||||
**udevadm monitor** 命令提供了许多很好的信息，但是你可以使用 **udevadm info** 命令以更好看的格式来看到它，假如你知道你的 U 盘当前已经位于你的 **/dev** 树。如果不在这个树下，拔下它并重新插入，然后立即运行这个命令：
|
||||
|
||||
```
|
||||
$ su -c 'dmesg | tail | fgrep -i sd*'
|
||||
```
|
||||
|
||||
举例来说，如果那个命令返回 **sdb: sdb1**，说明内核已经给你的 U 盘分配了 **sdb** 卷标。
|
||||
|
||||
或者，你可以使用 **lsblk** 命令去查看所有附加到你的系统上的驱动器，包括它的大小和分区。
|
||||
|
||||
现在，你的驱动器已经处于你的文件系统中了，你可以使用下面的命令去查看那个设备的相关 udev 信息：
|
||||
|
||||
```
|
||||
# udevadm info -a -n /dev/sdb | less
|
||||
```
|
||||
|
||||
这个命令将返回许多信息。现在我们只关心信息中的第一个块。
|
||||
|
||||
你的任务是从 udev 的报告中找出能唯一标识那个设备的部分，然后当计算机检测到这些唯一属性时，告诉 udev 去触发你的脚本。
|
||||
|
||||
**udevadm info** 命令处理一个（由设备路径指定的）设备上的报告，接着“遍历”父级设备链。对于找到的大多数设备，它以一个“键值对”格式输出所有可能的属性。你可以写一个规则，从一个单个的父级设备属性上去匹配插入设备的属性。
|
||||
|
||||
```
|
||||
looking at device '/devices/000:000/blah/blah//block/sdb':
|
||||
KERNEL=="sdb"
|
||||
SUBSYSTEM=="block"
|
||||
DRIVER==""
|
||||
ATTR{ro}=="0"
|
||||
ATTR{size}=="125722368"
|
||||
ATTR{stat}==" 2765 1537 5393"
|
||||
ATTR{range}=="16"
|
||||
ATTR{discard\_alignment}=="0"
|
||||
ATTR{removable}=="1"
|
||||
ATTR{blah}=="blah"
|
||||
```
|
||||
|
||||
一个 udev 规则必须包含来自单个父级设备的一个属性。
|
||||
|
||||
父级属性是描述一个设备的最基本的东西，比如它是插入到一个物理端口的东西、或是一个多大的东西、或这是一个可移除的设备。
|
||||
|
||||
由于内核卷标 **sdb** 可能会由于分配给在它之前插入的其它驱动器而发生变化，因此卷标并不是一个 udev 规则的父级属性的好选择。但是，在做概念论证时你可以使用它。一个事件的最佳候选者是 SUBSYSTEM 属性，它表示那个设备是一个 “block” 系统设备（也就是为什么我们要使用 **lsblk** 命令来列出设备的原因）。
|
||||
|
||||
在 **/etc/udev/rules.d** 目录中打开一个名为 **80-local.rules** 的文件，然后输入如下代码：
|
||||
|
||||
```
|
||||
SUBSYSTEM=="block", ACTION=="add", RUN+="/usr/local/bin/trigger.sh"
|
||||
```
|
||||
|
||||
保存文件，拔下你的测试 U 盘，然后重启动系统。
|
||||
|
||||
等等，重启动 Linux 机器？
|
||||
|
||||
理论上说，你只需要运行 **udevadm control —reload** 即可，它将重新加载所有规则，但是在我们实验的现阶段，最好要排除可能影响实验结果的所有因素。Udev 是非常复杂的，为了不让你躺在床上整晚都在思考为什么这个规则不能正常工作，是因为语法错误吗？还是应该重启动一下。所以，不管 POSIX 自负地告诉你过什么，你都应该去重启动一下。
|
||||
|
||||
当你的系统重启动完毕之后，（使用 Ctl+Alt+F3 或类似快捷键）切换到一个文本控制台，并插入你的 U 盘。如果你运行了一个最新的内核，当你插入 U 盘后你或许可以看到一大堆输出。如果看到一个错误信息，比如 “Could not execute /usr/local/bin/trigger.sh”，或许是因为你忘了授予这个脚本可运行的权限。否则你将看到的是，一个设备插入，它得到内核设备分配的一些东西，等等。
|
||||
|
||||
现在，见证奇迹的时刻到了。
|
||||
|
||||
```
|
||||
$ cat /tmp/udev.log
|
||||
Tue Oct 31 01:35:28 NZDT 2035
|
||||
```
|
||||
|
||||
如果你在 **/tmp/udev.log** 中看到了最新的日期和时间，那么说明 udev 已经成功触发了你的脚本。
|
||||
|
||||
### 改进规则做一些有用的事情
|
||||
|
||||
现在的问题是使用的规则太通用了。插入一个鼠标、一个 U 盘、或某个人的 U 盘都将盲目地触发这个脚本。现在，我们开始专注于希望触发你的脚本的是确定的某个 U 盘。
|
||||
|
||||
实现上述目标的一种方式是使用提供商 ID 和产品 ID。你可以使用 **lsusb** 命令去得到这些数字。
|
||||
|
||||
```
|
||||
$ lsusb
|
||||
Bus 001 Device 002: ID 8087:0024 Slacker Corp. Hub
|
||||
Bus 002 Device 002: ID 8087:0024 Slacker Corp. Hub
|
||||
Bus 003 Device 005: ID 03f0:3307 TyCoon Corp.
|
||||
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 hub
|
||||
Bus 001 Device 003: ID 13d3:5165 SBo Networks
|
||||
```
|
||||
|
||||
在这个例子中，**TyCoon Corp** 前面的 **03f0:3307** 就表示了提供商 ID 和产品 ID 的属性。你也可以通过 **udevadm info -a -n /dev/sdb | grep vendor** 的输出来查看这些数字，但是从 **lsusb** 的输出中可以很容易地一眼找到这些数字。
|
||||
|
||||
现在，可以在你的脚本中包含这些属性了。
|
||||
|
||||
```
|
||||
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/thumb.sh"
|
||||
```
|
||||
|
||||
测试它（是的，为了确保不会有来自 udev 的影响因素，我们仍然建议先重新启动一下），它应该会像前面一样工作，现在，如果你插入一个不同公司制造的 U 盘（因为它们的提供商 ID 不一样）、或插入一个鼠标、或插入一个打印机，这个脚本将不会被触发。
|
||||
|
||||
继续添加新属性来进一步专注于你希望去触发你的脚本的那个唯一的 U 盘。使用 **udevadm info -a -n /dev/sdb** 命令，你可以找出像提供商名字、序列号、或产品名这样的东西。
|
||||
|
||||
为了保证思路清晰，确保每次只添加一个新属性。我们（和在网上看到的其他人）在 udev 规则中所遇到的大多数错误都是因为一次添加了太多的属性，而奇怪为什么不能正常工作了。逐个测试属性是最安全的作法，这样可以确保 udev 能够成功识别到你的设备。
|
||||
|
||||
### 安全
|
||||
|
||||
编写 udev 规则当插入一个驱动器后自动去做一些事情，将带来安全方面的担忧。在我的机器上，我甚至都没有打开自动挂载功能，而基于本文的目的，当设备插入时，脚本和规则可以运行一些命令来做一些事情。
|
||||
|
||||
在这里需要记住两个事情。
|
||||
|
||||
1. 聚焦于你的 udev 规则，当你真实地使用它们时，一旦让规则发挥作用将触发脚本。执行一个脚本去盲目地复制数据到你的计算上，或从你的计算机上复制出数据，是一个很糟糕的主意，因为有可能会遇到一个人拿着和你相同品牌的 U 盘插入到你的机器上的情况。
|
||||
2. 不要在写了 udev 规则和脚本后忘记了它们的存在。我知道哪个计算上有我的 udev 规则，这些机器一般是我的个人计算机，而不是那些我带着去开会或办公室工作的计算机。一台计算机的 “社交” 程度越高，它就越不能有 udev 规则存在于它上面，因为它将潜在地导致我的数据最终可能会出现在某个人的设备、或某个人的数据中、或在我的设备上出现恶意程序。
|
||||
|
||||
|
||||
|
||||
换句话说就是，随着一个 GNU 系统提供了一个这么强大的功能，你的任务是小心地如何使用它们的强大功能。如果你滥用它或不小心谨慎地使用它，最终将让你出问题，它非常可能会导致可怕的问题。
|
||||
|
||||
### 现实中的 Udev
|
||||
|
||||
现在，你可以确认你的脚本是由 udev 触发的，那么，可以将你的关注点转到脚本功能上了。到目前为止，这个脚本是没有用的，它除了记录脚本已经运行过了这一事实外，再没有做更多的事情。
|
||||
|
||||
我使用 udev 去触发我的 U 盘的 [自动备份][2] 。这个创意是，将我正在处理的文档的主复本保存在我的 U 盘上（因为我随身带着它，这样就可以随时处理它），并且在我每次将 U 盘插入到那台机器上时，这些主文档将备份回我的计算机上。换句话说就是，我的计算机是备份驱动器，而产生的数据是移动的。源代码是可用的，你可以随意查看 attachup 的代码，以进一步限制你的 udev 的测试示例。
|
||||
|
||||
虽然我使用 udev 最多的情况就是这个例子，但是 udev 能抓取很多的事件，像游戏手柄（当连接游戏手柄时，让系统去加载 xboxdrv 模块）、摄像头、麦克风（当指定的麦克风连接时用于去设置输入），所以应该意识到，它能做的事情远比这个示例要多。
|
||||
|
||||
我的备份系统的一个简化版本是由两个命令组成的一个过程：
|
||||
|
||||
```
|
||||
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", SYMLINK+="safety%n"
|
||||
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/trigger.sh"
|
||||
```
|
||||
|
||||
第一行使用属性去检测我的 U 盘，这在前面已经讨论过了，接着在设备树中为我的 U 盘分配一个符号链接，给它分配的符号连接是 **safety%n**。这个 **%n** 是一个 udev 宏，它是内核分配给这个设备的任意数字，比如 sdb1、sdb2、sdb3、等等。因此 **%n** 应该是 1 或 2 或 3。
|
||||
|
||||
这将在 dev 树中创建一个符号链接，因此它不会干涉插入一个设备的正常过程。这意味着，如果你在自动挂载设备的桌面环境中使用它，将不会出现问题。
|
||||
|
||||
第二行运行这个脚本。
|
||||
|
||||
我的备份脚本如下：
|
||||
|
||||
```
|
||||
#!/usr/bin/bash
|
||||
|
||||
mount /dev/safety1 /mnt/hd
|
||||
sleep 2
|
||||
rsync -az /mnt/hd/ /home/seth/backups/ && umount /dev/safety1
|
||||
```
|
||||
|
||||
这个脚本使用符号链接，这将避免出现 udev 命名导致的意外情况（例如，假设一个命名为 DISK 的 U 盘已经插入到我的计算机上，而我插入的其它 U 盘恰好名字也是 DISK，那么第二个 U 盘的卷标将被命名为 `DISK_`，这将导致我的脚本不会正常运行），它在我喜欢的挂载点 **/mnt/hd** 上挂载了 **safety1**（驱动器的第一个分区）。
|
||||
|
||||
一旦 safely 挂载之后，它将使用 [rsync][3] 将驱动器备份到我的备份文件夹（我真实使用的脚本用的是 rdiff-backup，而你可以使用任何一个你喜欢的自动备份解决方案）。
|
||||
|
||||
### Udev 让你的设备你做主
|
||||
|
||||
Udev 是一个非常灵活的系统，它可以让你用其它系统很少敢提供给用户的方式去定义规则和功能。学习它，使用它，去享受 POSIX 的强大吧。
|
||||
|
||||
本文内容来自 [Slackermedia Handbook][4]，它以 [GNU Free Documentation License 1.3][5] 许可证授权使用。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/11/udev
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://linux.die.net/man/8/udev
|
||||
[2]: https://gitlab.com/slackermedia/attachup
|
||||
[3]: https://opensource.com/article/17/1/rsync-backup-linux
|
||||
[4]: http://slackermedia.info/handbook/doku.php?id=backup
|
||||
[5]: http://www.gnu.org/licenses/fdl-1.3.html
|
||||
@ -0,0 +1,307 @@
|
||||
关于 top 工具的 6 个替代方案
|
||||
======
|
||||
|
||||
|
||||
|
||||
在 GitHub 和 GitLab 上，不断有来自世界各地的开源应用程序和工具涌现。其中有全新的应用程序，也有针对现有各种被广泛使用的 Linux 程序的替代方案。在本文档中，我会介绍一些针对 [`top`][1] 工具（也就是命令行任务管理器程序）的替代方案。
|
||||
|
||||
### top 工具的替代方案
|
||||
|
||||
在本文中，将会介绍以下 6 种 `top` 工具的替代方案：
|
||||
|
||||
1. Htop
|
||||
2. Vtop
|
||||
3. Gtop
|
||||
4. Gotop
|
||||
5. Ptop
|
||||
6. Hegemon
|
||||
|
||||
如果后续有更多类似的工具，原作者会在原文进行更新。如果你对此有兴趣，可以持续关注。
|
||||
|
||||
#### Htop
|
||||
|
||||
`htop` 是一个流行的开源跨平台交互式进程管理器，也是我最喜欢的系统活动监控工具。`htop` 是对原版 `top` 工具的扩展。它最初只是用于 Linux 系统，后来开发者们不断为其添加对其它类 Unix 操作系统的支持，包括 FreeBSD 和 Mac OS。`htop` 还是一个自由开源软件，它基于 ncurses 并按照 GPLv2 发布。
|
||||
|
||||
和原版的 `top` 工具相比，`htop` 工具有这些优势：
|
||||
|
||||
* `htop` 比 `top` 启动更快
|
||||
* `htop` 支持横向滚动和纵向滚动浏览进程列表，以便看到所有的进程和完整的命令行
|
||||
* 在 `top` 工具中进行杀死进程、更改进程优先级这些操作时，需要输入进程 ID，而在 `htop` 工具中则不需要输入
|
||||
* 在 `htop` 中可以同时杀死多个进程
|
||||
* 在 `top` 中每次输入一个未预设的键都要等待一段时间，尤其是在多个键组成转义字符串的时候就更麻烦了
|
||||
|
||||
在很多 Linux 发行版的默认软件仓库中，都带有了 `htop`。
|
||||
|
||||
在基于 Arch 的操作系统中则可以执行以下命令来安装 `htop`：
|
||||
|
||||
```
|
||||
$ sudo pacman -S htop
|
||||
```
|
||||
|
||||
在基于 Debian 的操作系统使用以下命令：
|
||||
|
||||
```
|
||||
$ sudo apt install htop
|
||||
```
|
||||
|
||||
在使用 RPM 软件管理的操作系统使用以下命令：
|
||||
|
||||
```
|
||||
$ sudo dnf install htop
|
||||
```
|
||||
|
||||
或者
|
||||
|
||||
```
|
||||
$ sudo yum install htop
|
||||
```
|
||||
|
||||
在 openSUSE 系统中：
|
||||
|
||||
```
|
||||
$ sudo zypper in htop
|
||||
```
|
||||
|
||||
**用法**
|
||||
|
||||
不带任何参数执行 `htop` 时，会显示如下画面：
|
||||
|
||||
```
|
||||
$ htop
|
||||
```
|
||||
|
||||
|
||||
从图上可以看出，`htop` 会在界面顶部显示内存、交换空间、任务总数、系统平均负载、系统正常运行时间这些常用指标，在下方则和 `top` 一样显示进程列表，并且将进程的 ID、用户、进程优先级、进程 nice 值、虚拟内存使用情况、CPU 使用情况、内存使用情况等信息以多列显示出来。如果你想详细了解这些数据的含义，可以在[这里][1]阅读参考。
|
||||
|
||||
和 `top` 不同的是，`htop` 支持对不同的操作使用专有的按键。以下列出一些用于与 `htop` 交互的快捷键：
|
||||
|
||||
* `F1`、`h`、`?`：进入帮助界面。
|
||||
* `F2`、`Shift+s`：进入设置界面。在设置界面中可以配置仪表板界面顶部显示哪些数据，以及设置颜色方案、显示列、显示顺序等等多种参数。
|
||||
* `F3`、`/`：在进程列表中进行搜索。
|
||||
* `F4`、`\`：进入筛选模式。输入一个字符串，筛选出包含这个字符串的进程。进入筛选模式后再按一次 `F4` 或者 `ESC` 可以退出筛选模式。
|
||||
* `F5`、`t`：切换默认显示模式和树型显示模式，在树型显示模式下按 `+` 可以查看子树。
|
||||
* `F6`、`<`、`>`：依次按照进程 ID、用户、进程优先级、进程 nice 值、CPU 使用率、内存使用率排序显示。
|
||||
* `F7`、`]`：提高所选进程的优先级。
|
||||
* `F8`、`[`：降低所选进程的优先级。
|
||||
* `F9`、`k`：杀死所选进程。可以用 `↑` / `↓` 键选择不同的进程并按 `F9` 杀死进程。
|
||||
* `F10`、`q`： 退出 `htop`
|
||||
|
||||
|
||||
|
||||
以上这些快捷键都在 `htop` 界面底部显示。
|
||||
|
||||
需要注意的是，这其中有一些快捷键可能会与已有的快捷键发生冲突。例如按 `F2` 之后可能没有进入 `htop` 的设置界面，而是开始了对终端窗口的重命名。在这种情况下，你可能要更改一下快捷键的设置。
|
||||
|
||||
除了以上列出的快捷键以外，还有一些带有其它功能的快捷键，例如：
|
||||
|
||||
* `u` 可以选择显示某个用户的进程。
|
||||
* `Shift+m` 可以按照内存使用量对进程列表排序。
|
||||
* `Shift+p` 可以按照 CPU 使用量对进程列表排序。
|
||||
* `Shit+t` 可以按照进程启动时间对进程列表排序。
|
||||
* `CTRL+l` 刷新界面。
|
||||
|
||||
|
||||
|
||||
`htop` 的所有功能都可以在启动后通过快捷键来调用，而不需要在启动的时候带上某个参数。当然，`htop` 也支持带参数启动。
|
||||
|
||||
例如按照以下方式启动 `htop` 就可以只显示某个用户的进程：
|
||||
|
||||
```
|
||||
$ htop -u <username>
|
||||
```
|
||||
|
||||
更改界面自动刷新的时间间隔：
|
||||
|
||||
```kan
|
||||
$ htop -d 10
|
||||
```
|
||||
|
||||
看，`htop` 确实比 `top` 好用多了。
|
||||
|
||||
想了解 `htop` 的更多细节，可以查阅它的手册页面：
|
||||
|
||||
```
|
||||
$ man htop
|
||||
```
|
||||
|
||||
也可以查看它的[项目主页](http://hisham.hm/htop/)和 [GitHub 仓库](https://github.com/hishamhm/htop)。
|
||||
|
||||
#### Vtop
|
||||
|
||||
`vtop` 是 `top` 工具的另一个替代方案。它是一个使用 NodeJS 编写的、自由开源的命令行界面系统活动监视器，并使用 MIT 许可发布。`vtop` 通过使用 unicode 中的盲文字符来绘制 CPU 和内存使用情况的可视化图表。
|
||||
|
||||
在安装 `vtop` 之前，需要先安装 NodeJS。如果还没有安装 NodeJS，可以按照[这个教程](https://www.ostechnix.com/install-node-js-linux/)进行安装。
|
||||
|
||||
NodeJS 安装完毕之后，执行以下命令安装 `vtop`：
|
||||
|
||||
```
|
||||
$ npm install -g vtop
|
||||
```
|
||||
|
||||
安装好 `vtop` 就可以执行以下命令开始监控了。
|
||||
|
||||
```
|
||||
$ vtop
|
||||
```
|
||||
|
||||
显示界面如下：
|
||||
|
||||
![][3]
|
||||
|
||||
如上图所示，`vtop` 界面和 `top`、`htop` 都有所不同，它将不同的内容分别以多个盒子的布局显示。另外在界面底部也展示了用于与 `vtop` 交互的所有快捷键。
|
||||
|
||||
`vtop` 有这些快捷键：
|
||||
|
||||
* `dd` ：杀死一个进程。
|
||||
* `↑`、`k`：向上移动。
|
||||
* `↓`、`j`：向下移动。
|
||||
* `←`、`h` ：放大图表。
|
||||
* `→`、`l`：缩小图表。
|
||||
* `g` ：跳转到进程列表顶部。
|
||||
* `Shift+g` ：跳转到进程列表底部。
|
||||
* `c` ：以 CPU 使用量对进程排序。
|
||||
* `m` ：以内存使用量对进程排序。
|
||||
|
||||
|
||||
|
||||
想要了解更多关于 `vtop` 的细节，可以查阅它的[项目主页](http://parall.ax/vtop)或者 [GitHub 仓库](https://github.com/MrRio/vtop)。
|
||||
|
||||
#### Gtop
|
||||
|
||||
`gtop` 和 `vtop` 一样，都是一个使用 NodeJS 编写、在 MIT 许可下发布的系统活动监视器。
|
||||
|
||||
执行以下命令安装 `gtop`：
|
||||
|
||||
```
|
||||
$ npm install gtop -g
|
||||
```
|
||||
|
||||
然后执行以下命令启动：
|
||||
|
||||
```
|
||||
$ gtop
|
||||
```
|
||||
|
||||
显示界面如下：
|
||||
|
||||
|
||||
|
||||
`gtop` 有一个好，就是它会以不同的颜色来显示不同的模块，这种表现形式非常清晰明了。
|
||||
|
||||
主要的快捷键包括：
|
||||
|
||||
* `p`：按照进程 ID 对进程排序。
|
||||
* `c`：按照 CPU 使用量对进程排序。
|
||||
* `m`：按照内存使用量对进程排序。
|
||||
* `q`、`Ctrl+c`：退出。
|
||||
|
||||
|
||||
|
||||
想要了解更多关于 `gtop` 的细节，可以查阅它的 [GitHub 仓库](https://github.com/aksakalli/gtop)。
|
||||
|
||||
#### Gotop
|
||||
|
||||
`gotop` 也是一个完全自由和开源的图表式系统活动监视器。顾名思义，它是在受到 `gtop` 和 `vtop` 的启发之后用 Go 语言编写的，因此也不再对其展开过多的赘述了。如果你有兴趣了解这个项目，可以阅读《[gotop：又一个图表式系统活动监视器](https://www.ostechnix.com/manage-python-packages-using-pip/)》这篇文章。
|
||||
|
||||
#### Ptop
|
||||
|
||||
有些人对 NodeJS 和 Go 语言的项目可能不太感冒。如果你也是其中之一，你可以试一下使用 Python 编写的 `ptop`。它同样是一个自由开源的、在 MIT 许可下发布的系统活动监视器。
|
||||
|
||||
`ptop` 同时兼容 Python2.x 和 Python3.x，因此可以使用 Python 的软件包管理器 `pip` 轻松安装。如果你没有安装 `pip`，也可以参考[这个教程](https://www.ostechnix.com/manage-python-packages-using-pip/)进行安装。
|
||||
|
||||
安装 `pip` 之后，执行以下命令就可以安装 `ptop`：
|
||||
|
||||
```
|
||||
$ pip install ptop
|
||||
```
|
||||
|
||||
又或者按照以下方式通过源代码安装：
|
||||
|
||||
```
|
||||
$ git clone https://github.com/darxtrix/ptop
|
||||
$ cd ptop/
|
||||
$ pip install -r requirements.txt # install requirements
|
||||
$ sudo python setup.py install
|
||||
```
|
||||
|
||||
如果需要对 `ptop` 进行更新，可以这样操作：
|
||||
|
||||
```
|
||||
$ pip install --upgrade ptop
|
||||
```
|
||||
|
||||
即使你不执行更新，`ptop` 也会在第一次启动的时候提示你是否需要更新到最新的版本。
|
||||
|
||||
现在可以看一下启动 `ptop` 后的界面。
|
||||
|
||||
```
|
||||
$ ptop
|
||||
```
|
||||
|
||||
就像下面这样：
|
||||
|
||||
|
||||
`ptop` 的快捷键包括以下这些：
|
||||
|
||||
* `Ctrl+k`：杀死一个进程。
|
||||
* `Ctrl+n`：按照内存使用量对进程排序。
|
||||
* `Ctrl+t`：按照进程启动时间对进程排序。
|
||||
* `Ctrl+r`：重置所有数据。
|
||||
* `Ctrl+f`：对进程进行筛选，输入进程的名称就能够筛选出符合条件的进程。
|
||||
* `Ctrl+l`：查看所选进程的详细信息。
|
||||
* `g`：跳转到进程列表顶部。
|
||||
* `Ctrl+q`：退出。
|
||||
|
||||
|
||||
|
||||
`ptop` 还支持更改显示主题。如果你想让 `ptop` 更好看，可以选择你喜欢的主题。可用的主题包括以下这些：
|
||||
|
||||
* colorful
|
||||
* elegant
|
||||
* simple
|
||||
* dark
|
||||
* light
|
||||
|
||||
|
||||
|
||||
如果需要更换主题（例如更换到 colorful 主题），可以执行以下命令：
|
||||
|
||||
```
|
||||
$ ptop -t colorful
|
||||
```
|
||||
|
||||
使用 `-h` 参数可以查看帮助页面：
|
||||
|
||||
```
|
||||
$ ptop -h
|
||||
```
|
||||
|
||||
想要了解更多关于 `ptop` 的细节，可以查阅它的 [GitHub 仓库](https://github.com/darxtrix/ptop)。
|
||||
|
||||
#### Hegemon
|
||||
|
||||
`hegemon` 是一个使用 Rust 编写的系统活动监视器，如果你对 Rust 感兴趣，也可以了解一下。我们最近有一篇关于 `hegemon` 的[文章](https://www.ostechnix.com/hegemon-a-modular-system-monitor-application-written-in-rust/)，想要详细了解的读者不妨阅读。
|
||||
|
||||
### 总结
|
||||
|
||||
以上就是关于 `top` 工具的 6 个替代方案。我并不会说它们比 `top` 更好或者可以完全替代 `top`，但多了解一些类似的工具总是好的。你有使用过这些工具吗？哪个是你最喜欢的？欢迎在评论区留言。
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/some-alternatives-to-top-command-line-utility-you-might-want-to-know/
|
||||
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[HankChow](https://github.com/HankChow)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.ostechnix.com/author/sk/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.ostechnix.com/the-top-command-tutorial-with-examples-for-beginners/
|
||||
[2]: data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7
|
||||
[3]: http://www.ostechnix.com/wp-content/uploads/2018/11/vtop.png
|
||||
|
||||
@ -0,0 +1,70 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: subject: (Drive a locomotive through your Linux terminal)
|
||||
[#]: via: (https://opensource.com/article/18/12/linux-toy-sl)
|
||||
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
|
||||
[#]: url: ( )
|
||||
|
||||
在 Linux 终端中开火车
|
||||
======
|
||||
使用 sl 命令，你可以让自己坐上火车，有一个有趣的命令行体验。
|
||||
|
||||
|
||||
现在是 12 月，每个 Linux 终端用户都值得这一年的奖励。因此, 我们将为你带来一个 Linux 命令行玩具的出现日历。什么是命令行玩具？它可能是一个游戏、一个小的无意义的打发时间的东西，或者为你在终端带来快乐的东西。
|
||||
|
||||
今天的 Linux 命令行玩具是来自 Opensource.com 社区版主 [Ben Cotton][1] 的建议。Ben 建议 `sl`，它是蒸汽机车的简称。
|
||||
|
||||
对于 Linux **ls** 命令来说，它也是一个常见的错误，而不是巧合。想要不再打错吗？尝试安装 **sl**。它可能已经在默认仓库中打包。对我而言，在 Fedora 中，这意味着安装起来很简单：
|
||||
|
||||
```
|
||||
$ sudo dnf install sl -y
|
||||
```
|
||||
|
||||
现在，只需键入**sl** 即可测试。
|
||||
|
||||
|
||||
|
||||
你可能会像我一样注意到，**Ctrl+C** 不会让你的火车脱轨，所以你必须等待整列火车通过。这会让你知道打错了 **ls**！
|
||||
|
||||
|
||||
想查看 **sl** 源码？它已经在[在 GitHub 上][2]。
|
||||
|
||||
**sl** 也是分享关于开源许可的个人 PSA 的绝佳机会。虽然它的[许可证][3]“足够开源”以便为我的发行版打包，但技术上而言，它并不是 [OSI 批准][4]的许可证。在版权行之后，许可证的内容很简单:
|
||||
|
||||
```
|
||||
Everyone is permitted to do anything on this program including copying,
|
||||
modifying, and improving, unless you try to pretend that you wrote it.
|
||||
i.e., the above copyright notice has to appear in all copies.
|
||||
THE AUTHOR DISCLAIMS ANY RESPONSIBILITY WITH REGARD TO THIS SOFTWARE.
|
||||
```
|
||||
|
||||
遗憾的是，当你选择未经 OSI 批准的许可证时，你可能会意外地为你的用户带来额外的工作，因为他们必须要弄清楚你的许可证是否适用于他们的情况。他们的公司政策是否允许他们做贡献？甚至他们可以合法地使用该程序吗？许可证是否与他们希望与之集成的其他程序的许可证相匹配？
|
||||
|
||||
除非你是律师（也许，即使你是律师），否则在非标准许可证范围内选择可能会很棘手。因此，如果你仍在寻找新年的方案，为什么不把仅 OSI 批准的许可证作为你 2019 年新项目的选择呢。
|
||||
|
||||
这并不是对作者的不尊重。**sl** 仍然是一个很棒的小命令行玩具。
|
||||
|
||||
你有一个你认为我应该介绍的最喜欢的命令行玩具吗？这个系列的日历大部分已经完成，但我还剩下几个空余。请在下面的评论中告诉我，我会了解一下。如果有空间，我会尝试包含它。如果没有，但我得到了一些好的投稿，我会在最后做一些荣誉介绍。
|
||||
|
||||
了解昨天的玩具，[在 Linux 命令行中装饰字符][5]，还有记得明天再来！
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/linux-toy-sl
|
||||
|
||||
作者：[Jason Baker][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jason-baker
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/users/bcotton
|
||||
[2]: https://github.com/mtoyoda/sl
|
||||
[3]: https://github.com/mtoyoda/sl/blob/master/LICENSE
|
||||
[4]: https://opensource.org/licenses
|
||||
[5]: https://opensource.com/article/18/12/linux-toy-boxes
|
||||
Loading…
Reference in New Issue
Block a user