When installed, games from Steam are registered in Windows’ uninstall list as well as in Steam.
The uninstall items in “add / remove programs” serve little purpose as they are links directly to Steam’s app management (easily accessed from Steam’s UI), and if you relocate your Steam folder these will become broken.
The following is two commands to run and a downloadable batch file (also contains an admin check) that remove all Steam apps from the Windows uninstall list.
I figure it may come in handy if someone can’t be bothered writing or doesn’t know how to write it themselves.
You will need to run these with administrative privileges.
screen -d -r should do the trick.
This is a combination of two commands.
screen -d detaches the already-running screen session, and screen -r reattaches the existing session.
By running screen -d -r, you force screen to detach it and then resume the session.
Option 2: List displays
Short answer
Reattach without ejecting others: screen -x
Get list of displays: ^A *, select the one to disconnect, press D
Explained answer
PREFIX is usually ^A = Ctrl + A .
Reattach a session: screen -x.
-x attach to a not detached screen session without detaching it.
List displays of this session: PREFIX *.
It is the default key binding for: PREFIX :displays.
Performing it within the screen, identify the other display we want to disconnect (e.g. smaller size).
(Your current display is displayed in brighter color/bold when not selected).
term-type size user interface window Perms ---------- ------- ---------- ----------------- ---------- ----- screen 240x60 you@/dev/pts/2 nb 0(zsh) rwx screen 78x40 you@/dev/pts/0 nb 0(zsh) rwx
Using arrows ↑↓ , select the targeted display, press D .
If nothing happens, you tried to detach your own display and screen will not detach it.
If it was another one, within a second or two, the entry will disappear.
The classic Linux way of doing this sort of thing goes something like this:
Create the shared folder:
sudo mkdir /home/shared
Create the new user's group:
sudo addgroup sharespace
Change ownership of the shared folder to the new group:
sudo chown :sharespace /home/shared
Add your desired users to that group:
sudo adduser user1 sharespace
Repeat for all users.
Now you have some decisions to make about what you want those users to be able to do:
All group users can add to and delete from the folder and can read and but not write to each others files:
sudo chmod 0770 /home/shared
Same as above but only the owner of the file can delete it:
sudo chmod 1770 /home/shared
All group users can add to and delete from the folder and can read and write to each other's files:
sudo chmod 2770 /home/shared
Same as choice 3 except only the owner of the file can delete it:
sudo chmod 3770 /home/shared
A 1 in the first position of the chmod command is the sticky bit which prevents deletion of a file to anyone other than the owner.
A 2 in the first position of the chmod command is the setgid bit which forces all new or copied files to have the group of that folder.
A 3 in the first position of the chmod command is the combination of the sticky (1) & setgid (+2) bits.
There is one caveat to all this as far as the setgid bit is concerned.
All new files created in and any files copied to that folder will in fact inherit the group of the folder.
But not files moved to that folder.
Moved files retain the ownership from wherever they were moved from.
One way to get past this problem is to use bindfs.
Finally if you want others outside the group to be able to see the files but not change them change the final 0 in the chmod command to a 5:
If there is only one job, then you don't need to specify the job number.
Just use disown -h and bg.
Explanation of the above steps:
You press Ctrl+Z.
The system suspends the running program, displays a job number and a "Stopped" message and returns you to a bash prompt.
You type the disown -h %1 command (here, I've used a 1, but you'd use the job number that was displayed in the Stopped message) which marks the job so it ignores the SIGHUP signal (it will not be stopped by logging out).
Next, type the bg command using the same job number; this resumes the running of the program in the background and a message is displayed confirming that.
If your system uses journalctl then you can easily get the kernel messages (dmesg log) from prior shutdown/crash (in a dmesg -T format) through the following.
Options:
-k Show kernel messages.
-b <boot_number> How many reboots ago 0, -1, -2, etc.
-o short-precise Print in a dmesg -T format.
-p <priority> Filter by priority output (4 to filter out notice and info).
There is also an -o short and -o short-iso which gives you the date only, and the date-time in ISO format respectively.
Commands:
All boot cycles : journalctl -o short-precise -k -b all
Current boot : journalctl -o short-precise -k
Last boot : journalctl -o short-precise -k -b -1
Two boots prior : journalctl -o short-precise -k -b -2
And so on.
The amount of boots you can look back on can be viewed with the following.
journalctl --list-boot
The output of journalctl --list-boot looks like the following.
Like any other operating system, GNU/Linux has implemented memory management efficiently and even more than that.
But if any process is eating away your memory and you want to clear it, Linux provides a way to flush or clear ram cache.
How to Clear Cache in Linux?
Every Linux System has three options to clear cache without interrupting any processes or services.
As the root user:
Clear PageCache only.
sync; echo 1 > /proc/sys/vm/drop_caches
Clear dentries and inodes.
sync; echo 2 > /proc/sys/vm/drop_caches
Clear pagecache, dentries, and inodes.
sync; echo 3 > /proc/sys/vm/drop_caches
Explanation of the above command
sync will flush the file system buffer.
Command Separated by ; run sequentially.
The shell waits for each command to terminate before executing the next command in the sequence.
As mentioned in the kernel documentation, writing to drop_cache will clean cache without killing any application/service, command echo is doing the job of writing to file.
If you have to clear the disk cache, the first command is safest in enterprise and production as ...echo 1 >... will clear the PageCache only.
It is not recommended to use the third option above ...echo 3 >... in production until you know what you are doing, as it will clear pagecache, dentries, and inodes.
How to Clear Swap Space in Linux?
If you want to clear Swap space, you may like to run the below command.
While it might seem like a clear-cut idea, actually there is ambiguity in the meaning of human user.
Is a user account deliberately hidden from the login screen because it's used only for specialized purposes (but by humans) a human user?
How about the ubuntu user (UID 999) on the live CD? And guest accounts in Ubuntu are created on-the-fly and destroyed after logout; are they human users?
More examples could be devised.
Therefore, it's fitting that multiple, non-equivalent answers have been given.
Saige Hamblin's solution of running ls /home is what people actually do, and unless you're writing a script, you should probably just use that.
Making ls /home More Robust
But perhaps you have users that have been removed, but whose home directories still exist in /home, and you must avoid listing them.
Or maybe for some other reason you must ensure only the entries in /home that correspond to real accounts are listed.
In that case, I suggest passing the names of everything in /home to getent (to retrieve the passwd entries of users with those names), then isolate and display just the username field (with grep, sed, or awk, as per your preference).
Any one of these will do:
getent passwd $(ls /home) | grep -o '^[^:]*'
getent passwd $(ls /home) | sed 's/:.*//'
getent passwd $(ls /home) | awk -F: '{print $1}'
This should work well, as you shouldn't have user accounts with whitespace or control characters in their names; cannot, without reconfiguring Ubuntu to allow it; and if you do, you have bigger problems.
Thus the usual problems with parsing ls are inapplicable.
But even though it's really okay here, if you consider command substitutions with ls aesthetically displeasing or just a bad habit, you may prefer:
getent passwd $(basename -a /home/*) | grep -o '^[^:]*'
getent passwd $(basename -a /home/*) | sed 's/:.*//'
getent passwd $(basename -a /home/*) | awk -F: '{print $1}'
These don't accommodate whitespace or control characters either.
I provide them only because $(ls /home) looks wrong even when it is right, and thus rubs many users the wrong way.
In most situations, there are real, good reasons to avoid parsing ls, and in those situations parsing basename -a is usually only very slightly less bad.
In this situation, however, due to the limitation on what characters may practically occur in usernames, they are both fine.
The options usrquota and grpquota enables quotas on the filesystem for both users and groups.
Ensure that you add the new options separated by a comma and no spaces.