https://wiki.archlinux.org/api.php?action=feedcontributions&user=Voxadam&feedformat=atomArchWiki - User contributions [en]2024-03-28T19:28:11ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=459109Unified Extensible Firmware Interface2016-12-12T11:54:55Z<p>Voxadam: emphasis</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|EFI System Partition}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related|UEFI/Hardware}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations ''may'' carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular mainboard model before proceeding.}}<br />
<br />
The [http://www.uefi.org/ Unified Extensible Firmware Interface] (EFI or UEFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications.<br />
<br />
It is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI Boot Loaders, see [[Boot loaders]].<br />
<br />
== UEFI versions ==<br />
* UEFI started as Intel's EFI in versions 1.x.<br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0.<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware.<br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
The latest UEFI Specification can be found at http://uefi.org/specifications.<br />
<br />
== UEFI Firmware bitness ==<br />
<br />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware bitness/architecture.<br />
<br />
The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use IA32 (32-bit) EFI are older (pre 2008) Apple Macs, some Intel Cloverfield ultrabooks and some older Intel Server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
An x86_64 EFI firmware does not include support for launching 32-bit EFI apps (unlike x86_64 Linux and Windows versions which include such support). Therefore the UEFI application must be compiled for that specific firmware processor bitness/architecture.<br />
<br />
=== Non Macs ===<br />
<br />
Check whether the dir {{ic|/sys/firmware/efi}} exists, if it exists it means the kernel has booted in EFI mode. In that case the UEFI bitness is same as kernel bitness. (ie. i686 or x86_64)<br />
<br />
{{Note|Intel Atom System-on-Chip systems ship with 32-bit UEFI (as on 2 November 2013). See [[#Booting 64-bit kernel on 32-bit UEFI]] for more info.}}<br />
<br />
=== Apple Macs ===<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.<br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
If the command returns EFI32 then it is IA32 (32-bit) EFI firmware. If it returns EFI64 then it is x86_64 EFI firmware. Most of the Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI 2.x Specification.<br />
<br />
== Linux Kernel Config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI Runtime Variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt .<br />
<br />
== UEFI Variables ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up. UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc. You can get the list using<br />
$ efivar -l<br />
<br />
=== UEFI Variables Support in Linux Kernel ===<br />
<br />
Linux kernel exposes EFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# Kernel processor [[#UEFI Firmware bitness|bitness]] and EFI processor bitness should match.<br />
# Kernel should be booted in EFI mode (via [[EFISTUB]] or any [[Boot loaders|EFI boot loader]], not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM).<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}) the EFI Variables without any error.<br />
<br />
If EFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify efi variables data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel efi variable storage space check that may prevent writing/modification of efi variables.<br />
<br />
{{Note|{{ic|efi_no_storage_paranoia}} should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
{{Warning|1=''efivars'' is mounted writeable by default [https://github.com/systemd/systemd/issues/2402], which may cause permanent damage to the system. [https://bbs.archlinux.org/viewtopic.php?id=207549]{{Dead link|2016|08|21}} As such, consider mounting ''efivars'' read-only ({{ic|-o ro}}) as described below. Note that when it is mounted read-only, tools such as ''efibootmgr'' and bootloaders will not be able to change boot settings, nor will commands like {{ic|systemctl reboot --firmware-setup}} work.}}<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools]] like {{ic|efibootmgr}}:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
To mount {{ic|efivarfs}} read-only during boot, add to {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|2=<br />
efivarfs /sys/firmware/efi/efivars efivarfs '''ro''',nosuid,nodev,noexec,noatime 0 0<br />
}}<br />
<br />
To remount with write support, run:<br />
<br />
# mount -o remount /sys/firmware/efi/efivars -o '''rw''',nosuid,nodev,noexec,noatime<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
* {{App|efivar|Library and Tool to manipulate UEFI Variables (used by efibootmgr)|https://github.com/vathpela/efivar|{{Pkg|efivar}}, {{AUR|efivar-git}}}}<br />
* {{App|efibootmgr|Tool to manipulate UEFI Firmware Boot Manager Settings|https://github.com/vathpela/efibootmgr|{{Pkg|efibootmgr}}, {{AUR|efibootmgr-git}}}}<br />
* {{App|uefivars|Dumps list of EFI variables with some additional PCI related info (uses efibootmgr code internally)|https://github.com/fpmurphy/Various/tree/master/uefivars-2.0|{{AUR|uefivars-git}}}}<br />
* {{App|efitools|Tools for manipulating UEFI secure boot platforms|http://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git|{{Pkg|efitools}}, {{AUR|efitools-git}}}}<br />
* {{App|Ubuntu's Firmware Test Suite|Test suite that performs sanity checks on Intel/AMD PC firmware|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts-git}}}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Note|<br />
* If ''efibootmgr'' does not work on your system, you can reboot into [[#UEFI Shell]] and use {{ic|bcfg}} to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage uefi boot entries from within its boot-time interface. For example, some ASUS firmwares have an "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI application location e.g. {{ic|\EFI\refind\refind_x64.efi}}.<br />
* The below commands use [[rEFInd]] boot-loader as example.<br />
}}<br />
<br />
To add a new boot option using ''efibootmgr'' you need to know three things:<br />
<br />
# The disk containing the ESP: {{ic|/dev/sd''X''}}<br />
# The partition number of the ESP on that disk: the {{ic|''Y''}} in {{ic|/dev/sdX''Y''}}<br />
# The path to the UEFI application (relative to the root of the ESP)<br />
<br />
For example, if you want to add a boot option for {{ic|/boot/efi/EFI/refind/refind_x64.efi}} where {{ic|/boot/efi}} is the mount point of the ESP, run<br />
<br />
{{hc|$ findmnt /boot/efi|2=<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sda1 vfat rw,flush,tz=UTC<br />
}}<br />
<br />
In this example, this indicates that the ESP is on disk {{ic|/dev/sda}} and has partition number 1. The path to the UEFI application relative to the root of the ESP is {{ic|/EFI/refind/refind_x64.efi}}. So you would create the boot entry as follows:<br />
<br />
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager"<br />
<br />
See {{man|8|efibootmgr|url=}} or [https://raw.githubusercontent.com/rhinstaller/efibootmgr/master/README efibootmgr README] for more info.<br />
<br />
{{Note|1=UEFI uses backward slash {{ic|\}} as path separator but ''efibootmgr'' automatically converts UNIX-style {{ic|/}} path separators.}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc.<br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project:<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Precompiled UEFI Shell v2 binaries] (may not be up-to-date)<br />
* [https://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream)<br />
* [http://dl.dropbox.com/u/17629062/Shell2.zip Precompiled UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware] - from Clover EFI bootloader<br />
<br />
Shell v2 works best in UEFI 2.3+ systems and is recommended over Shell v1 in those systems. Shell v1 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]{{Dead link|2016|08|21}}<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI System Partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/efi/boot/bootx64.efi}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. See [[#Obtaining UEFI Shell]] for a modified UEFI Shell v2 binary which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|fs0:}} is the mapping corresponding to the EFI System Partition and {{ic|fs0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|fs0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> fs0:<br />
fs0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI System Partition ({{ic|fs0:}} in the firmware),<br />
<br />
Shell> edit FS0:\EFI\refind\refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI Linux Hardware Compatibility ==<br />
<br />
See [[Unified Extensible Firmware Interface/Hardware]] for more information.<br />
<br />
== UEFI Bootable Media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI Bootable USB]]<br />
<br />
=== Remove UEFI boot support from Optical Media ===<br />
<br />
{{Note|This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media), not from a USB flash drive.}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI Optical Media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for Virtual Machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly<br />
<br />
As shorter alternative, {{Pkg|ovmf}} can be loaded using {{ic|-bios}} parameter<br />
<br />
$ qemu-system-x86_64 -enable-kvm -m 1G -bios /usr/share/ovmf/ovmf_x64.bin<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
DUET is a tianocore project that enables chainloading a full UEFI environment from a BIOS system, in a way similar to BIOS OS booting. This method is being discussed extensively in http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/. Pre-build DUET images can be downloaded from one of the repos at https://gitorious.org/tianocore_uefi_duet_builds {{Dead link|2016|08|21}}. Specific instructions for setting up DUET is available at https://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blobs/raw/master/Migle_BootDuet_INSTALL.txt {{Dead link|2016|08|21}}.<br />
<br />
You can also try http://sourceforge.net/projects/cloverefiboot/ which provides modified DUET images that may contain some system specific fixes and is more frequently updated compared to the gitorious repos.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI Mode ===<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen UEFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop.<br />
* If your motherboard is booting the default UEFI path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different UEFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set {bootmgr} path \EFI\''path''\''to''\''app.efi''}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set {fwbootmgr} DEFAULT ''{copied boot identifier}''}}<br />
*# Open ''gpedit'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
This issue can occur due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
=== Booting 64-bit kernel on 32-bit UEFI ===<br />
<br />
Both Official ISO ([[Archiso]]) and [[Archboot]] iso use EFISTUB (via [[systemd-boot]] Boot Manager for menu) for booting the kernel in UEFI mode. In such a case you have to use [[GRUB]] as the USB's UEFI bootloader by following the below section.<br />
<br />
==== Using GRUB ====<br />
{{Tip|The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].}}<br />
<br />
* [[USB flash installation media#BIOS_and_UEFI_Bootable_USB|Create an USB Flash Installation]]<br />
<br />
* Backup {{ic|EFI/boot/loader.efi}} to {{ic|EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_standalone|Create a GRUB standalone image]] and copy the generate {{ic|grub*.efi}} to the USB as {{ic|EFI/boot/loader.efi}} and/or {{ic|EFI/boot/bootia32.efi}}<br />
<br />
* Create {{ic|EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{hc|grub.cfg for Official ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap<br />
initrd /arch/boot/x86_64/archiso.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
{{hc|grub.cfg for Archboot ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux x86_64 Archboot" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap<br />
initrd /boot/initramfs_x86_64.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On certain UEFI motherboards like some boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the EFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the {{ic|.efi}} file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
FS1:<br />
cd EFI<br />
mkdir Microsoft<br />
cd Microsoft<br />
mkdir Boot<br />
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]{{Dead link|2016|07|16}}<br />
* [http://firmware.intel.com/ Intel Architecture Firmware Resource Center]<br />
* [http://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]<br />
* [http://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]<br />
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [https://jdebp.eu/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]{{Dead link|2016|08|21}}<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]{{Dead link|2016|08|21}}<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Network_configuration&diff=459015Network configuration2016-12-11T02:42:23Z<p>Voxadam: Added note regarding hostnamectl not working while in a chroot environment</p>
<hr />
<div>[[Category:Network configuration]]<br />
[[cs:Network configuration]]<br />
[[el:Network configuration]]<br />
[[es:Network configuration]]<br />
[[fr:Connexions reseau]]<br />
[[it:Network configuration]]<br />
[[ja:ネットワーク設定]]<br />
[[nl:Network configuration]]<br />
[[pt:Network configuration]]<br />
[[ro:Configurare retea]]<br />
[[ru:Network configuration]]<br />
[[sk:Network configuration]]<br />
[[tr:Ağ Yapılandırması]]<br />
[[zh-cn:Network configuration]]<br />
[[zh-tw:Network configuration]]<br />
{{Related articles start}}<br />
{{Related|Jumbo frames}}<br />
{{Related|Firewalls}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|Network bridge}}<br />
{{Related|List of applications/Internet#Network managers}}<br />
{{Related articles end}}<br />
<br />
This page explains how to set up a '''wired''' connection to a network. If you need to set up '''wireless''' networking see the [[Wireless network configuration]] page.<br />
<br />
== Check the connection ==<br />
<br />
The basic installation procedure typically has a functional network configuration. Use {{man|8|ping}} to check the connection:<br />
<br />
{{hc|$ ping www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
...<br />
}}<br />
<br />
If the ping is successful (you see 64 bytes messages as above), then the network is configured. Press {{ic|Control-C}} to stop the ping.<br />
<br />
If the ping failed with an ''Unknown hosts'' error, it means that your machine was unable to resolve this domain name. It may be related to your service provider or your router/gateway. Try pinging a static IP address to prove that your machine has access to the Internet:<br />
<br />
{{hc|$ ping 8.8.8.8|<nowiki><br />
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.<br />
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=52.9 ms<br />
...<br />
</nowiki>}}<br />
<br />
If you are able to ping {{ic|8.8.8.8}} but not {{ic|www.google.com}}, check your DNS configuration. See [[resolv.conf]] for details. The {{ic|hosts}} line in {{ic|/etc/nsswitch.conf}} is another place you can check.<br />
<br />
If not, check for cable issues before diagnosing further.<br />
<br />
{{Note|<br />
* If you receive an error like {{ic|ping: icmp open socket: Operation not permitted}} when executing ''ping'', try to re-install the {{Pkg|iputils}} package.<br />
* The {{ic|-c ''num''}} option can be used to make exactly {{ic|''num''}} pings, otherwise it pings infinitely and has to be terminated manually. See {{man|8|ping}} for more information.<br />
* {{ic|8.8.8.8}} is a static address that is easy to remember. It is the address of Google's primary DNS server, therefore it can be considered reliable, and is generally not blocked by content filtering systems and proxies.<br />
}}<br />
<br />
== Set the hostname ==<br />
<br />
A [[Wikipedia:Hostname|hostname]] is a unique name created to identify a machine on a network, configured in {{ic|/etc/hostname}}—see {{man|5|hostname}} and {{man|7|hostname}} for details. The file can contain the system's domain name, if any. To set the hostname, [[textedit|edit]] {{ic|/etc/hostname}} to include a single line with {{ic|''myhostname''}}:<br />
<br />
{{hc|/etc/hostname|<br />
''myhostname''<br />
}}<br />
<br />
{{Tip|For advice on choosing a hostname, see [https://tools.ietf.org/html/rfc1178 RFC 1178].}}<br />
<br />
Alternatively, using {{man|1|hostnamectl}}:<br />
{{Tip|It is not possible to set a machine's hostname using hostnamectl while in a chroot environment. The above method of writing to /etc/hostname directly should be used while installing a new system.}}<br />
# hostnamectl set-hostname ''myhostname''<br />
<br />
To temporarily set the hostname (until reboot), use {{man|1|hostname}} from {{Pkg|inetutils}}:<br />
<br />
# hostname ''myhostname''<br />
<br />
To set the "pretty" hostname and other machine metadata, see {{man|5|machine-info|https://www.freedesktop.org/software/systemd/man/machine-info.html}}.<br />
<br />
=== Local network hostname resolution ===<br />
<br />
The pre-requisite is to [[#Set the hostname]], after which hostname resolution works on the local system itself:<br />
<br />
{{hc|$ ping ''myhostname''|2=<br />
PING myhostname (192.168.1.2) 56(84) bytes of data.<br />
64 bytes from myhostname (192.168.1.2): icmp_seq=1 ttl=64 time=0.043 ms}}<br />
<br />
To allow other machines to address the host by name, it is necessary to either:<br />
<br />
* Configure the {{man|5|hosts}} file, or<br />
* Enable a service which resolves the hostname.<br />
<br />
{{Note|1={{Pkg|systemd}} provides hostname resolution via the {{ic|myhostname}} nss module, enabled by default in {{ic|/etc/nsswitch.conf}}. However, clients may still rely on {{ic|/etc/hosts}}, see [https://lists.debian.org/debian-devel/2013/07/msg00809.html] [https://bugzilla.mozilla.org/show_bug.cgi?id=87717#c55] for examples.}}<br />
<br />
To configure the hosts file, add the following line to {{ic|/etc/hosts}}:<br />
<br />
127.0.1.1 ''myhostname''.localdomain ''myhostname''<br />
<br />
As a result the system resolves to both entries: <br />
<br />
{{hc|$ getent hosts|<br />
127.0.0.1 localhost<br />
127.0.1.1 myhostname.localdomain myhostname<br />
}}<br />
<br />
For a system with a permanent IP address, that permanent IP address should be used instead of {{ic|127.0.1.1}}. <br />
<br />
{{Note|1=Another option is to set up a full DNS server such as [[BIND]] or [[Unbound]], but that is overkill and too complex for most systems. For small networks and dynamic flexibility with hosts joining and leaving the network [[Wikipedia:Zero-configuration_networking|zero-configuration networking]] services may be more applicable:<br />
*[[Samba]] provides hostname resolution via Microsoft's '''NetBIOS'''. It only requires installation of {{Pkg|samba}} and enabling of the {{ic|nmbd.service}} service. Computers running Windows, macOS, or Linux with {{ic|nmbd}} running, will be able to find your machine.<br />
*[[Avahi]] provides hostname resolution via '''zeroconf''', also known as Avahi or Bonjour. It requires slightly more complex configuration than Samba: see [[Avahi#Hostname resolution]] for details. Computers running macOS, or Linux with an Avahi daemon running, will be able to find your machine. Windows does not have an built-in Avahi client or daemon.<br />
}}<br />
<br />
== Device driver ==<br />
<br />
=== Check the status ===<br />
<br />
[[udev]] should detect your network interface card (see [[Wikipedia:Network interface controller]]) and automatically load the necessary module at start up. Check the "Ethernet controller" entry (or similar) from the {{ic|lspci -v}} output. It should tell you which kernel module contains the driver for your network device. For example:<br />
<br />
{{hc|$ lspci -v|<br />
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)<br />
...<br />
Kernel driver in use: atl1<br />
Kernel modules: atl1<br />
}}<br />
<br />
Next, check that the driver was loaded via {{ic|dmesg <nowiki>|</nowiki> grep ''module_name''}}. For example:<br />
<br />
{{hc|<nowiki>$ dmesg | grep atl1</nowiki>|<br />
...<br />
atl1 0000:02:00.0: eth0 link is up 100 Mbps full duplex<br />
}}<br />
<br />
Skip the next section if the driver was loaded successfully. Otherwise, you will need to know which module is needed for your particular model.<br />
<br />
=== Load the module ===<br />
<br />
Search in the Internet for the right module/driver for the chipset. Some common modules are {{ic|8139too}} for cards with a Realtek chipset, or {{ic|sis900}} for cards with a SiS chipset. Once you know which module to use, try to [[Kernel modules#Manual module handling|load it manually]]. If you get an error saying that the module was not found, it's possible that the driver is not included in Arch kernel. You may search the [[AUR]] for the module name.<br />
<br />
If udev is not detecting and loading the proper module automatically during bootup, see [[Kernel modules#Automatic module handling]].<br />
<br />
== Network interfaces ==<br />
<br />
=== Device names ===<br />
<br />
For computers with multiple NICs, it is important to have fixed device names. Many configuration problems are caused by interface name changing.<br />
<br />
[[udev]] is responsible for which device gets which name. Systemd v197 introduced [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Predictable Network Interface Names], which automatically assigns static names to network devices. Interfaces are now prefixed with {{ic|en}} (wired/[[w:Ethernet|Ethernet]]), {{ic|wl}} (wireless/WLAN), or {{ic|ww}} ([[w:Wireless_WAN|WWAN]]) followed by an automatically generated identifier, creating an entry such as {{ic|enp0s25}}. This behavior may be disabled by adding {{ic|1=net.ifnames=0}} to the [[kernel parameters]].<br />
<br />
{{Note|When changing the interface naming scheme, do not forget to update all network-related configuration files and custom systemd unit files to reflect the change. Specifically, if you have [[netctl#Basic method|netctl static profiles]] enabled, run {{ic|netctl reenable ''profile''}} to update the generated service file.}}<br />
<br />
==== Get current device names ====<br />
<br />
Current NIC names can be found via {{ic|sysfs}} or {{ic|ip link}}. For example:<br />
<br />
{{hc|$ ls /sys/class/net|<br />
lo enp0s3<br />
}}<br />
<br />
{{hc|$ ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default <br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000<br />
link/ether 08:00:27:23:6f:3a brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Wireless device names can also be retrieved using {{ic|iw dev}}. See [[Wireless network configuration#Getting some useful information]] for details.<br />
<br />
==== Change device name ====<br />
<br />
You can change the device name by defining the name manually with an udev-rule. For example:<br />
<br />
{{hc|/etc/udev/rules.d/10-network.rules|<nowiki><br />
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net1"<br />
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="net0"<br />
</nowiki>}}<br />
<br />
These rules will be applied automatically at boot.<br />
<br />
A couple of things to note:<br />
<br />
* To get the MAC address of each card, use this command: {{ic|cat /sys/class/net/''device_name''/address}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
<br />
If the network card has a dynamic MAC, you can use {{ic|DEVPATH}}, for example:<br />
<br />
{{hc|/etc/udev/rules.d/10-network.rules|<nowiki><br />
SUBSYSTEM=="net", DEVPATH=="/devices/platform/wemac.*", NAME="int"<br />
SUBSYSTEM=="net", DEVPATH=="/devices/pci*/*1c.0/*/net/*", NAME="en"<br />
</nowiki>}}<br />
<br />
The device path should match both the new and old device name, since the rule may be executed more than once on bootup. For example, in the second rule, {{ic|"/devices/pci*/*1c.0/*/net/enp*"}} would be wrong since it will stop matching once the name is changed to {{ic|en}}. Only the system-default rule will fire the second time around, causing the name to be changed back to e.g. {{ic|enp1s0}}.<br />
<br />
To [[Udev#Testing_rules_before_loading|test]] your rules, they can be triggered directly from userspace, e.g. with {{ic|udevadm --debug test /sys/''DEVPATH''}}. Remember to first take down the interface you are trying to rename (e.g. {{ic|ip link set enp1s0 down}}).<br />
<br />
{{Note|When choosing the static names '''it should be avoided to use names in the format of "eth''X''" and "wlan''X''"''', because this may lead to race conditions between the kernel and udev during boot. Instead, it is better to use interface names that are not used by the kernel as default, e.g.: {{ic|net0}}, {{ic|net1}}, {{ic|wifi0}}, {{ic|wifi1}}. For further details please see the [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames systemd] documentation.}}<br />
<br />
==== Reverting to traditional device names ====<br />
<br />
If you would prefer to retain traditional interface names such as eth0, [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Predictable Network Interface Names] can be disabled with the following:<br />
<br />
# ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules<br />
<br />
=== Set device MTU and queue length ===<br />
<br />
You can change the device MTU and queue length by defining manually with an udev-rule. For example:<br />
<br />
{{hc|/etc/udev/rules.d/10-network.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", ATTR{mtu}="1480", ATTR{tx_queue_len}="2000"<br />
</nowiki>}}<br />
<br />
=== Enabling and disabling network interfaces ===<br />
<br />
You can activate or deactivate network interfaces using:<br />
<br />
# ip link set eth0 up<br />
# ip link set eth0 down<br />
<br />
To check the result:<br />
<br />
{{hc|$ ip link show dev eth0|<br />
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000<br />
...<br />
}}<br />
<br />
{{Note| If your default route is through interface {{ic|eth0}}, taking it down will also remove the route, and bringing it back up will not automatically reestablish the default route. See [[#Manual assignment]] for reestablishing it.}}<br />
<br />
== Configure the IP address ==<br />
<br />
{{Warning|Use a single method to manage the network, as several methods may conflict.}}<br />
<br />
You have two options: a dynamically assigned address using [[Wikipedia:Dynamic Host Configuration Protocol|DHCP]], or an unchanging "static" address. See also [[List of applications#Network managers]].<br />
<br />
=== Dynamic IP address ===<br />
<br />
==== systemd-networkd ====<br />
<br />
An easy way to setup DHCP for simple requirements is to use [[systemd-networkd]] service provided by systemd. See [[systemd-networkd#Basic DHCP network]]. <br />
<br />
==== dhcpcd ====<br />
<br />
[[dhcpcd]] is the default client in Arch Linux to setup DHCP on the installation ISO. It is a powerful tool with many configurable DHCP client options. See [[dhcpcd#Running]] on how to activate it for an interface.<br />
<br />
==== dhclient ====<br />
<br />
{{Pkg|dhclient}} is the Internet Systems Consortium DHCP client. [[Enable]] the {{ic|dhclient@''interface''.service}}, where {{ic|''interface''}} is a wired [[#Device name]]. See {{man|8|dhclient|url=}} and {{man|5|dhclient.conf|url=}} for details.<br />
<br />
==== netctl ====<br />
<br />
[[netctl]] is a CLI-based tool for configuring and managing network connections through user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
=== Static IP address ===<br />
<br />
A static IP address can be configured with most standard Arch Linux networking tools. Independent of the tool you choose, you will probably need to be prepared with the following information:<br />
<br />
* Static IP address<br />
* Subnet mask, or possibly its [[wikipedia:Classless Inter-Domain Routing#CIDR notation|CIDR notation]], for example {{ic|/24}} is the CIDR notation of {{ic|255.255.255.0}} netmask.<br />
* [[Wikipedia:Broadcast_address|Broadcast address]]<br />
* [[Wikipedia:Default_gateway|Gateway]]'s IP address<br />
* Name server (DNS) IP addresses. See also [[resolv.conf]].<br />
<br />
If you are running a private network, it is safe to use IP addresses in {{ic|192.168.*.*}} for your IP addresses, with a subnet mask of {{ic|255.255.255.0}} and a broadcast address of {{ic|192.168.*.255}}. The gateway is usually {{ic|192.168.*.1}} or {{ic|192.168.*.254}}.<br />
<br />
{{Warning|<br />
* Make sure manually assigned IP addresses do not conflict with DHCP assigned ones. See [http://www.raspberrypi.org/forums/viewtopic.php?f&#61;28&t&#61;16797 this forum thread].<br />
* If you share your Internet connection from a Windows machine without a router, be sure to use static IP addresses on both computers to avoid LAN problems.<br />
}}<br />
<br />
{{Tip|Addresses can be calculated with the {{Pkg|ipcalc}} package; see [[#Calculating addresses]].}}<br />
<br />
==== netctl ====<br />
<br />
To create a [[netctl]] profile with a static IP, set the {{ic|1=IP=static}} option as well as {{ic|Address}}, {{ic|Gateway}}, and {{ic|DNS}}. See [[netctl#Wired]].<br />
<br />
==== systemd-networkd ====<br />
<br />
The [[systemd-networkd]] service provided by systemd can set up a static IP using a simple configuration file. See [[systemd-networkd#Wired adapter using a static IP]].<br />
<br />
==== dhcpcd ====<br />
<br />
See [[dhcpcd#Static profile]].<br />
<br />
==== Manual assignment ====<br />
<br />
It is possible to manually set up a static IP using only the {{pkg|iproute2}} package. This is a good way to test connection settings since the connection made using this method will not persist across reboots. First enable the [[#Network interfaces|network interface]]:<br />
<br />
# ip link set ''interface'' up<br />
<br />
Assign a static IP address in the console:<br />
<br />
# ip addr add ''IP_address''/''subnet_mask'' broadcast ''broadcast_address'' dev ''interface''<br />
<br />
Then add your gateway IP address:<br />
<br />
# ip route add default via ''default_gateway''<br />
<br />
For example:<br />
<br />
# ip link set eth0 up<br />
# ip addr add 192.168.1.2/24 broadcast 192.168.1.255 dev eth0<br />
# ip route add default via 192.168.1.1<br />
<br />
{{Tip|If you get the message {{ic|RTNETLINK answers: Network is unreachable}}, try to break up the route creation in the following two parts:<br />
<br />
# ip route add 192.168.1.1 dev eth0<br />
# ip route add default via 192.168.1.1 dev eth0<br />
}}<br />
<br />
To undo these steps (e.g. before switching to a dynamic IP), first remove any assigned IP address:<br />
<br />
# ip addr flush dev ''interface''<br />
<br />
Then remove any assigned gateway:<br />
<br />
# ip route flush dev ''interface''<br />
<br />
And finally disable the interface:<br />
<br />
# ip link set ''interface'' down<br />
<br />
For more options, see the {{man|8|ip}}. These commands can be automated using scripts and [[systemd#Writing unit files|systemd units]].<br />
<br />
==== Calculating addresses ====<br />
<br />
You can use {{ic|ipcalc}} provided by the {{Pkg|ipcalc}} package to calculate IP broadcast, network, netmask, and host ranges for more advanced configurations. An example is using Ethernet over Firewire to connect a Windows machine to Linux. To improve security and organization, both machines have their own network with the netmask and broadcast configured accordingly. <br />
<br />
Finding out the respective netmask and broadcast addresses is done with {{ic|ipcalc}}, by specifying the IP of the Linux NIC {{ic|10.66.66.1}} and the number of hosts (here two):<br />
<br />
{{hc|$ ipcalc -nb 10.66.66.1 -s 1|<nowiki><br />
Address: 10.66.66.1<br />
<br />
Netmask: 255.255.255.252 = 30<br />
Network: 10.66.66.0/30<br />
HostMin: 10.66.66.1<br />
HostMax: 10.66.66.2<br />
Broadcast: 10.66.66.3<br />
Hosts/Net: 2 Class A, Private Internet<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== ifplugd for laptops ===<br />
<br />
{{Tip|[[dhcpcd]] provides the same feature out of the box.}}<br />
<br />
{{Pkg|ifplugd}} in [[official repositories]] is a daemon which will automatically configure your Ethernet device when a cable is plugged in and automatically unconfigure it if the cable is pulled. This is useful on laptops with onboard network adapters, since it will only configure the interface when a cable is really connected. Another use is when you just need to restart the network but do not want to restart the computer or do it from the shell.<br />
<br />
By default it is configured to work for the {{ic|eth0}} device. This and other settings like delays can be configured in {{ic|/etc/ifplugd/ifplugd.conf}}.<br />
<br />
{{Note|[[netctl]] package includes {{ic|netctl-ifplugd@.service}}, otherwise you can use {{ic|ifplugd@.service}} from {{Pkg|ifplugd}} package. For example, [[enable]] {{ic|ifplugd@eth0.service}}.}}<br />
<br />
=== Bonding or LAG ===<br />
<br />
See [[netctl#Bonding]] or [[Wireless bonding]].<br />
<br />
=== IP address aliasing ===<br />
<br />
IP aliasing is the process of adding more than one IP address to a network interface. With this, one node on a network can have multiple connections to a network, each serving a different purpose. Typical uses are virtual hosting of Web and FTP servers, or reorganizing servers without having to update any other machines (this is especially useful for nameservers).<br />
<br />
==== Example ====<br />
<br />
To manually set an alias, for some NIC, use {{Pkg|iproute2}} to execute<br />
<br />
# ip addr add 192.168.2.101/24 dev eth0 label eth0:1<br />
<br />
To remove a given alias execute<br />
<br />
# ip addr del 192.168.2.101/24 dev eth0:1<br />
<br />
Packets destined for a subnet will use the primary alias by default. If the destination IP is within a subnet of a secondary alias, then the source IP is set respectively. Consider the case where there is more than one NIC, the default routes can be listed with {{ic|ip route}}.<br />
<br />
=== Change MAC/hardware address ===<br />
<br />
See [[MAC address spoofing]].<br />
<br />
=== Internet sharing ===<br />
<br />
See [[Internet sharing]].<br />
<br />
=== Router configuration ===<br />
<br />
See [[Router]].<br />
<br />
=== Promiscuous mode ===<br />
<br />
Toggling [[wikipedia:Promiscuous_mode|promiscuous mode]] will make a (wireless) NIC forward all traffic it receives to the OS for further processing. This is opposite to "normal mode" where a NIC will drop frames it is not intended to receive. It is most often used for advanced network troubleshooting and [[wikipedia:Packet_sniffing|packet sniffing]].<br />
<br />
{{hc|/etc/systemd/system/promiscuous@.service|<nowiki><br />
[Unit]<br />
Description=Set %i interface in promiscuous mode<br />
After=network.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/ip link set dev %i promisc on<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
If you want to enable promiscuous mode on interface {{ic|eth0}} run [[enable]] {{ic|promiscuous@eth0.service}}.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Swapping computers on the cable modem ===<br />
<br />
Some cable ISPs (videotron for example) have the cable modem configured to recognize only one client PC, by the MAC address of its network interface. Once the cable modem has learned the MAC address of the first PC or equipment that talks to it, it will not respond to another MAC address in any way. Thus if you swap one PC for another (or for a router), the new PC (or router) will not work with the cable modem, because the new PC (or router) has a MAC address different from the old one. To reset the cable modem so that it will recognise the new PC, you must power the cable modem off and on again. Once the cable modem has rebooted and gone fully online again (indicator lights settled down), reboot the newly connected PC so that it makes a DHCP request, or manually make it request a new DHCP lease.<br />
<br />
If this method does not work, you will need to clone the MAC address of the original machine. See also [[#Change MAC/hardware address]].<br />
<br />
=== The TCP window scaling problem ===<br />
<br />
TCP packets contain a "window" value in their headers indicating how much data the other host may send in return. This value is represented with only 16 bits, hence the window size is at most 64Kb. TCP packets are cached for a while (they have to be reordered), and as memory is (or used to be) limited, one host could easily run out of it.<br />
<br />
Back in 1992, as more and more memory became available, [http://www.faqs.org/rfcs/rfc1323.html RFC 1323] was written to improve the situation: Window Scaling. The "window" value, provided in all packets, will be modified by a Scale Factor defined once, at the very beginning of the connection. That 8-bit Scale Factor allows the Window to be up to 32 times higher than the initial 64Kb.<br />
<br />
It appears that some broken routers and firewalls on the Internet are rewriting the Scale Factor to 0 which causes misunderstandings between hosts. The Linux kernel 2.6.17 introduced a new calculation scheme generating higher Scale Factors, virtually making the aftermaths of the broken routers and firewalls more visible.<br />
<br />
The resulting connection is at best very slow or broken.<br />
<br />
==== How to diagnose the problem ====<br />
<br />
First of all, let's make it clear: this problem is odd. In some cases, you will not be able to use TCP connections (HTTP, FTP, ...) at all and in others, you will be able to communicate with some hosts (very few).<br />
<br />
When you have this problem, the {{ic|dmesg}}'s output is OK, logs are clean and {{ic|ip addr}} will report normal status... and actually everything appears normal.<br />
<br />
If you cannot browse any website, but you can ping some random hosts, chances are great that you're experiencing this problem: ping uses ICMP and is not affected by TCP problems.<br />
<br />
You can try to use [[Wireshark]]. You might see successful UDP and ICMP communications but unsuccessful TCP communications (only to foreign hosts).<br />
<br />
==== Ways of fixing it ====<br />
<br />
===== Bad =====<br />
<br />
To fix it the bad way, you can change the {{ic|tcp_rmem}} value, on which Scale Factor calculation is based. Although it should work for most hosts, it is not guaranteed, especially for very distant ones.<br />
<br />
# echo "4096 87380 174760" > /proc/sys/net/ipv4/tcp_rmem<br />
<br />
===== Good =====<br />
<br />
Simply disable Window Scaling. Since Window Scaling is a nice TCP feature, it may be uncomfortable to disable it, especially if you cannot fix the broken router. There are several ways to disable Window Scaling, and it seems that the most bulletproof way (which will work with most kernels) is to add the following line to {{ic|/etc/sysctl.d/99-disable_window_scaling.conf}} (see also [[sysctl]]):<br />
<br />
net.ipv4.tcp_window_scaling = 0<br />
<br />
===== Best =====<br />
<br />
This problem is caused by broken routers/firewalls, so let's change them. Some users have reported that the broken router was their very own DSL router.<br />
<br />
==== More about it ====<br />
<br />
This section is based on the LWN article [http://lwn.net/Articles/92727/ TCP window scaling and broken routers] and a Kernel Trap article: [http://kerneltrap.org/node/6723 Window Scaling on the Internet].<br />
<br />
There are also several relevant threads on the LKML.<br />
<br />
=== Realtek no link / WOL problem ===<br />
<br />
Users with Realtek 8168 8169 8101 8111(C) based NICs (cards / and on-board) may notice a problem where the NIC seems to be disabled on boot and has no Link light. This can usually be found on a dual boot system where Windows is also installed. It seems that using the offical Realtek drivers (dated anything after May 2007) under Windows is the cause. These newer drivers disable the Wake-On-LAN feature by disabling the NIC at Windows shutdown time, where it will remain disabled until the next time Windows boots. You will be able to notice if this problem is affecting you if the Link light remains off until Windows boots up; during Windows shutdown the Link light will switch off. Normal operation should be that the link light is always on as long as the system is on, even during POST. This problem will also affect other operating systems without newer drivers (eg. Live CDs). Here are a few fixes for this problem.<br />
<br />
==== Enable the NIC directly in Linux ====<br />
<br />
Follow [[#Enabling and disabling network interfaces]] to enable the interface.<br />
<br />
==== Rollback/change Windows driver ====<br />
<br />
You can roll back your Windows NIC driver to the Microsoft provided one (if available), or roll back/install an official Realtek driver pre-dating May 2007 (may be on the CD that came with your hardware).<br />
<br />
==== Enable WOL in Windows driver ====<br />
<br />
Probably the best and the fastest fix is to change this setting in the Windows driver. This way it should be fixed system-wide and not only under Arch (eg. live CDs, other operating systems). In Windows, under Device Manager, find your Realtek network adapter and double-click it. Under the "Advanced" tab, change "Wake-on-LAN after shutdown" to "Enable".<br />
<br />
In Windows XP (example):<br />
<br />
Right click my computer and choose "Properties"<br />
--> "Hardware" tab<br />
--> Device Manager<br />
--> Network Adapters<br />
--> "double click" Realtek ...<br />
--> Advanced tab<br />
--> Wake-On-Lan After Shutdown<br />
--> Enable<br />
<br />
{{Note|Newer Realtek Windows drivers (tested with ''Realtek 8111/8169 LAN Driver v5.708.1030.2008'', dated 2009/01/22, available from GIGABYTE) may refer to this option slightly differently, like ''Shutdown Wake-On-LAN --> Enable''. It seems that switching it to {{ic|Disable}} has no effect (you will notice the Link light still turns off upon Windows shutdown). One rather dirty workaround is to boot to Windows and just reset the system (perform an ungraceful restart/shutdown) thus not giving the Windows driver a chance to disable LAN. The Link light will remain on and the LAN adapter will remain accessible after POST - that is until you boot back to Windows and shut it down properly again.}}<br />
<br />
==== Newer Realtek Linux driver ====<br />
<br />
Any newer driver for these Realtek cards can be found for Linux on the realtek site (untested but believed to also solve the problem).<br />
<br />
==== Enable ''LAN Boot ROM'' in BIOS/CMOS ====<br />
<br />
It appears that setting ''Integrated Peripherals --> Onboard LAN Boot ROM --> Enabled'' in BIOS/CMOS reactivates the Realtek LAN chip on system boot-up, despite the Windows driver disabling it on OS shutdown.<br />
<br />
{{Note|This was tested several times on a GIGABYTE GA-G31M-ES2L motherboard, BIOS version F8 released on 2009/02/05.}}<br />
<br />
=== No interface with Atheros chipsets ===<br />
<br />
Users of some Atheros ethernet chips are reporting it does not work out-of-the-box (with installation media of February 2014). The working solution for this is to install {{AUR|backports-patched}}.<br />
<br />
=== Broadcom BCM57780 ===<br />
<br />
This Broadcom chipset sometimes does not behave well unless you specify the order of the modules to be loaded. The modules are {{ic|broadcom}} and {{ic|tg3}}, the former needing to be loaded first.<br />
<br />
These steps should help if your computer has this chipset:<br />
<br />
* Find your NIC in ''lspci'' output:<br />
<br />
{{hc|<nowiki>$ lspci | grep Ethernet</nowiki>|<br />
02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM57780 Gigabit Ethernet PCIe (rev 01)<br />
}}<br />
<br />
* If your wired networking is not functioning in some way or another, try unplugging your cable then doing the following:<br />
<br />
# modprobe -r tg3<br />
# modprobe broadcom<br />
# modprobe tg3<br />
<br />
* Plug your network cable in. If this solves your problems you can make this permanent by adding {{ic|broadcom}} and {{ic|tg3}} (in this order) to the {{ic|MODULES}} array in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES=".. broadcom tg3 .."<br />
<br />
* Rebuild the initramfs:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Alternatively, you can create an {{ic|/etc/modprobe.d/broadcom.conf}}:<br />
<br />
softdep tg3 pre: broadcom<br />
<br />
{{Note|These methods may work for other chipsets, such as BCM57760.}}<br />
<br />
=== Realtek RTL8111/8168B ===<br />
<br />
{{hc|<nowiki># lspci | grep Ethernet</nowiki>|<br />
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)<br />
}}<br />
<br />
The adapter should be recognized by the {{ic|r8169}} module. However, with some chip revisions the connection may go off and on all the time. The alternative {{Pkg|r8168}} can be found in the [[official repositories]] and should be used for a reliable connection in this case. [[Blacklist]] {{ic|r8169}}, if {{Pkg|r8168}} is not automatically loaded by [[udev]], see [[Kernel modules#Automatic module handling]].<br />
<br />
{{Accuracy|"some revisions", no proof the driver is the cause, and not e.g poorly configured DNS servers}}<br />
<br />
Another fault in the drivers for some revisions of this adapter is poor IPv6 support. [[IPv6#Disable functionality]] can be helpful if you encounter issues such as hanging webpages and slow speeds.<br />
<br />
=== Gigabyte Motherboard with Realtek 8111/8168/8411 ===<br />
With motherboards such as the Gigabyte GA-990FXA-UD3, booting with IOMMU off (which can be the default) will cause the network interface to be unreliable, often failing to connect or connecting but allowing no throughput. This will apply not only to the onboard NIC, but any other pci-NIC you put in the box because the IOMMU setting affects the entire network interface on the board. Enabling IOMMU and booting with the install media will throw AMD I-10/xhci page faults for a second, but then boot normally, resulting in a fully functional onboard NIC (even with the r8169 module).<br />
<br />
When configuring the boot process for your installation, add {{ic|1=iommu=soft}} as a [[kernel parameter]] to eliminate the error messages on boot and restore USB3.0 functionality.<br />
<br />
== See also ==<br />
<br />
* [https://www.debian.org/doc/manuals/debian-reference/ch05.en.html Debian Reference: Network setup]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ RHEL7: Networking Guide]</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Sway&diff=440354Sway2016-07-08T05:40:41Z<p>Voxadam: typo</p>
<hr />
<div>[[Category:Tiling WMs]]<br />
[[Category:Dynamic WMs]]<br />
[[ja:Sway]]<br />
''sway'' is a compositor for [[Wayland]] designed to be fully compatible with [[i3]].<br />
{{quote|Sway is a drop-in replacement for the i3 window manager, but for Wayland instead of X11. It works with your existing i3 configuration and supports most of i3's features, and a few extras.|swaywm.org}}<br />
== Status ==<br />
Sway is a work-in-progress so caution is advised. However, the project's creator, [https://drewdevault.com/ Drew DeVault] (aka SirCmpwn) has deemed ready for regular use. <br />
<br />
A detailed accounting of what features have been implemented and what features are still outstanding can be found at the following links:<br />
*[https://github.com/SirCmpwn/sway/issues/2#issue-99897933 i3 feature support]<br />
*[https://github.com/SirCmpwn/sway/issues/98 IPC feature support]<br />
*[https://github.com/SirCmpwn/sway/issues/343 i3bar compatibility]<br />
*[https://github.com/SirCmpwn/sway/issues/307 Airblader fork features]<br />
<br />
== Installation ==<br />
<br />
''sway'' can be [[installed]] with the {{Pkg|sway}} package (or {{AUR|sway-git}} for the latest git version). If you already use i3, then copy your i3 configuration to {{ic|~/.config/sway/config}} and it will work out of the box. Otherwise, copy the sample configuration file to {{ic|~/.config/sway/config}}. It is located at {{ic|/etc/sway/config}}, unless the {{ic|DFALLBACK_CONFIG_DIR}} flag has been set. See the sway(5) [[man page]] for information on the configuration.<br />
<br />
== Starting sway ==<br />
=== From a terminal ===<br />
You can start sway by simply typing {{ic|sway}} in a terminal.<br />
<br />
=== Using a display manager ===<br />
The sway session is located at {{ic|/usr/share/wayland-sessions/sway.desktop}}. It is automatically recognized by GDM.<br />
<br />
=== From X ===<br />
If you want to start ''sway'' in an X session for testing purposes it is possible to start it as a regular program.<br />
<br />
== Configuration ==<br />
=== Keymap ===<br />
By default, sway starts with the US QWERTY keymap. You can override this behaviour by starting sway with<br />
$ XKB_DEFAULT_LAYOUT=gb XKB_DEFAULT_VARIANT=colemak XKB_DEFAULT_MODEL=pc101 sway<br />
This will launch sway with the keyboard set to the Colemak variant of the British keymap with the 101-key keyboard model.<br />
<br />
If you are using a display manager, you can not simply prepend the above line to the {{ic|sway.desktop}} file. As root, create the following file:<br />
{{hc|/usr/bin/sway-gb-ck|2=<br />
#!/bin/sh<br />
XKB_DEFAULT_LAYOUT=gb XKB_DEFAULT_VARIANT=colemak XKB_DEFAULT_MODEL=pc101 sway}}<br />
Then, create a {{ic|sway-gb-ck.desktop}} file that starts the above script:<br />
{{hc|/usr/share/wayland-sessions/sway.desktop|2=<br />
[Desktop Entry]<br />
Name=Sway British(Colemak)<br />
Comment=SirCmpwn's Wayland window manager with the British Colemak keyboard layout<br />
Exec=sway-gb-ck<br />
Type=Application<br />
}}<br />
<br />
=== Statusbar ===<br />
Installing the program {{Pkg|i3status}} is an easy way to get a practical, default statusbar. All one has to do is add following snippet at the end of your sway config:<br />
{{hc|~/.config/sway/config|<nowiki><br />
bar {<br />
status_command i3status<br />
}<br />
</nowiki>}}<br />
If you want to achieve colored output of i3status, you can adjust following part in the i3status configuration:<br />
{{hc|~/.config/i3status/config|<nowiki><br />
general {<br />
colors = true<br />
interval = 5<br />
}<br />
</nowiki>}}<br />
In both examples, the system-wide installed configuration files has been copied over to the user directory and then modified.<br />
<br />
=== Wallpaper ===<br />
This line, which can be appended at the end of your sway configuration, sets a background image on all displays (output matches all with name {{ic|"*"}}):<br />
{{hc|~/.config/sway/config|<nowiki><br />
output "*" background /home/onny/pictures/fredwang_norway.jpg fill<br />
</nowiki>}}<br />
Of course you have to replace the file name and path according to your wallpaper.<br />
<br />
=== Input devices ===<br />
Its possible to tweak specific input device configurations. For example to enable tap-to-click for a touchpad, add an input block:<br />
{{hc|~/.config/sway/config|<nowiki><br />
input "2:14:ETPS/2_Elantech_Touchpad" {<br />
tap enabled<br />
}<br />
</nowiki>}}<br />
Where as the device identifier can be queried with:<br />
swaymsg -t get_inputs<br />
Output from the command, sometimes has "\" to escape some symbols like "/" (ie {{ic|"2:14:ETPS\/2_Elantech_Touchpad"}}) and need to be removed<br />
<br />
More documentation and options like acceleration profiles can be found with <br />
man sway-input<br />
<br />
=== Custom keybindings ===<br />
[[Extra_keyboard_keys|Special keys]] on your keyboard can be used to execute commands, for example to control your volume or your monitor brightness:<br />
{{hc|~/.config/sway/config|<nowiki><br />
bindsym XF86AudioRaiseVolume exec pactl set-sink-volume 0 +15%<br />
bindsym XF86AudioLowerVolume exec pactl set-sink-volume 0 -15%<br />
bindsym XF86AudioToggle exec pactl set-sink-mute 0 toggle<br />
bindsym XF86MonBrightnessDown exec dsplight down 5<br />
bindsym XF86MonBrightnessUp exec dsplight up 5<br />
</nowiki>}}<br />
<br />
== Known issues ==<br />
<br />
=== Using i3-dmenu-desktop ===<br />
<br />
i3-dmenu-desktop is not usable directly from sway, but a patch is available here : https://github.com/i3/i3/pull/2265/files<br />
Unfortunately, the patch cannot be merged because it breaks when used from i3 in some corner cases.<br />
<br />
See here for more information: https://github.com/SirCmpwn/sway/issues/521<br />
<br />
You can still apply the patch manually though:<br />
<br />
<pre><br />
$ wget 'https://patch-diff.githubusercontent.com/raw/i3/i3/pull/2265.patch'<br />
# patch -p0 /usr/bin/i3-dmenu-desktop < 2265.patch<br />
</pre><br />
<br />
=== hidpi ===<br />
<br />
wlc (which sway relies on) does not currently support hidpi : https://github.com/Cloudef/wlc/issues/57<br />
<br />
== See also ==<br />
<br />
* [https://github.com/SirCmpwn/sway Github project]<br />
* [http://swaywm.org Website]</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Sway&diff=440353Sway2016-07-08T05:40:04Z<p>Voxadam: </p>
<hr />
<div>[[Category:Tiling WMs]]<br />
[[Category:Dynamic WMs]]<br />
[[ja:Sway]]<br />
''sway'' is a compositor for [[Wayland]] designed to be fully compatible with [[i3]].<br />
{{quote|Sway is a drop-in replacement for the i3 window manager, but for Wayland instead of X11. It works with your existing i3 configuration and supports most of i3's features, and a few extras.|swaywm.org}}<br />
== Status ==<br />
Sway is a work-in-progress so caution is advised. However, the project's creator, [https://drewdevault.com/ Drew DeVault] (aka SirCmpwn) has deemed ready for regular use. <br />
<br />
A detailed accounting of what features have been implemented and what features are still outstanding can be found at the following links:<br />
*[https://github.com/SirCmpwn/sway/issues/2#issue-99897933 i3 feature support]<br />
*[https://github.com/SirCmpwn/sway/issues/98|IPC feature support]<br />
*[https://github.com/SirCmpwn/sway/issues/343 i3bar compatibility]<br />
*[https://github.com/SirCmpwn/sway/issues/307 Airblader fork features]<br />
== Installation ==<br />
<br />
''sway'' can be [[installed]] with the {{Pkg|sway}} package (or {{AUR|sway-git}} for the latest git version). If you already use i3, then copy your i3 configuration to {{ic|~/.config/sway/config}} and it will work out of the box. Otherwise, copy the sample configuration file to {{ic|~/.config/sway/config}}. It is located at {{ic|/etc/sway/config}}, unless the {{ic|DFALLBACK_CONFIG_DIR}} flag has been set. See the sway(5) [[man page]] for information on the configuration.<br />
<br />
== Starting sway ==<br />
=== From a terminal ===<br />
You can start sway by simply typing {{ic|sway}} in a terminal.<br />
<br />
=== Using a display manager ===<br />
The sway session is located at {{ic|/usr/share/wayland-sessions/sway.desktop}}. It is automatically recognized by GDM.<br />
<br />
=== From X ===<br />
If you want to start ''sway'' in an X session for testing purposes it is possible to start it as a regular program.<br />
<br />
== Configuration ==<br />
=== Keymap ===<br />
By default, sway starts with the US QWERTY keymap. You can override this behaviour by starting sway with<br />
$ XKB_DEFAULT_LAYOUT=gb XKB_DEFAULT_VARIANT=colemak XKB_DEFAULT_MODEL=pc101 sway<br />
This will launch sway with the keyboard set to the Colemak variant of the British keymap with the 101-key keyboard model.<br />
<br />
If you are using a display manager, you can not simply prepend the above line to the {{ic|sway.desktop}} file. As root, create the following file:<br />
{{hc|/usr/bin/sway-gb-ck|2=<br />
#!/bin/sh<br />
XKB_DEFAULT_LAYOUT=gb XKB_DEFAULT_VARIANT=colemak XKB_DEFAULT_MODEL=pc101 sway}}<br />
Then, create a {{ic|sway-gb-ck.desktop}} file that starts the above script:<br />
{{hc|/usr/share/wayland-sessions/sway.desktop|2=<br />
[Desktop Entry]<br />
Name=Sway British(Colemak)<br />
Comment=SirCmpwn's Wayland window manager with the British Colemak keyboard layout<br />
Exec=sway-gb-ck<br />
Type=Application<br />
}}<br />
<br />
=== Statusbar ===<br />
Installing the program {{Pkg|i3status}} is an easy way to get a practical, default statusbar. All one has to do is add following snippet at the end of your sway config:<br />
{{hc|~/.config/sway/config|<nowiki><br />
bar {<br />
status_command i3status<br />
}<br />
</nowiki>}}<br />
If you want to achieve colored output of i3status, you can adjust following part in the i3status configuration:<br />
{{hc|~/.config/i3status/config|<nowiki><br />
general {<br />
colors = true<br />
interval = 5<br />
}<br />
</nowiki>}}<br />
In both examples, the system-wide installed configuration files has been copied over to the user directory and then modified.<br />
<br />
=== Wallpaper ===<br />
This line, which can be appended at the end of your sway configuration, sets a background image on all displays (output matches all with name {{ic|"*"}}):<br />
{{hc|~/.config/sway/config|<nowiki><br />
output "*" background /home/onny/pictures/fredwang_norway.jpg fill<br />
</nowiki>}}<br />
Of course you have to replace the file name and path according to your wallpaper.<br />
<br />
=== Input devices ===<br />
Its possible to tweak specific input device configurations. For example to enable tap-to-click for a touchpad, add an input block:<br />
{{hc|~/.config/sway/config|<nowiki><br />
input "2:14:ETPS/2_Elantech_Touchpad" {<br />
tap enabled<br />
}<br />
</nowiki>}}<br />
Where as the device identifier can be queried with:<br />
swaymsg -t get_inputs<br />
Output from the command, sometimes has "\" to escape some symbols like "/" (ie {{ic|"2:14:ETPS\/2_Elantech_Touchpad"}}) and need to be removed<br />
<br />
More documentation and options like acceleration profiles can be found with <br />
man sway-input<br />
<br />
=== Custom keybindings ===<br />
[[Extra_keyboard_keys|Special keys]] on your keyboard can be used to execute commands, for example to control your volume or your monitor brightness:<br />
{{hc|~/.config/sway/config|<nowiki><br />
bindsym XF86AudioRaiseVolume exec pactl set-sink-volume 0 +15%<br />
bindsym XF86AudioLowerVolume exec pactl set-sink-volume 0 -15%<br />
bindsym XF86AudioToggle exec pactl set-sink-mute 0 toggle<br />
bindsym XF86MonBrightnessDown exec dsplight down 5<br />
bindsym XF86MonBrightnessUp exec dsplight up 5<br />
</nowiki>}}<br />
<br />
== Known issues ==<br />
<br />
=== Using i3-dmenu-desktop ===<br />
<br />
i3-dmenu-desktop is not usable directly from sway, but a patch is available here : https://github.com/i3/i3/pull/2265/files<br />
Unfortunately, the patch cannot be merged because it breaks when used from i3 in some corner cases.<br />
<br />
See here for more information: https://github.com/SirCmpwn/sway/issues/521<br />
<br />
You can still apply the patch manually though:<br />
<br />
<pre><br />
$ wget 'https://patch-diff.githubusercontent.com/raw/i3/i3/pull/2265.patch'<br />
# patch -p0 /usr/bin/i3-dmenu-desktop < 2265.patch<br />
</pre><br />
<br />
=== hidpi ===<br />
<br />
wlc (which sway relies on) does not currently support hidpi : https://github.com/Cloudef/wlc/issues/57<br />
<br />
== See also ==<br />
<br />
* [https://github.com/SirCmpwn/sway Github project]<br />
* [http://swaywm.org Website]</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=440295Kernel/Traditional compilation2016-07-07T08:22:40Z<p>Voxadam: </p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. It can be, depending on your background, more complicated than using the [[Kernels/Arch Build System]]. Consider the [[Arch Build System]] tools are developed and maintained to make repeatable compilation tasks efficient and safe.<br />
<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified [[cgroups]] hierarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [[wikipedia:Tar (computing)|tarball]] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make clean && make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version in the {{ic| General Setup --->}} option using one of the user interfaces listed later. If you skip this, there is the risk of overwriting one of your existing kernels by mistake.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
* {{ic|make gconfig}}: Graphical configuration similar to xconfig but using gtk.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to {{ic|-march<nowiki>=</nowiki>native}} to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.<br />
<br />
* Note: For 32bit Kernels, you need to edit {{ic|arch/x86/Makefile_32.cpu}} instead and set {{ic|-march<nowiki>=</nowiki>native}} for your processor.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
{{Tip|If your system requires modules which are not distributed with the regular Linux kernel, you need to compile them for your custom kernel when it is finished. Such modules are typically those which you explicitly installed seperately for your running system. See [[NVIDIA#Alternate install: custom kernel]] for an example.}}<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified as a suffix to {{ic|/boot/vmlinuz-}} when copying the {{ic|bzImage}} (in this case, {{ic|linux318}}):<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note (again) that the {{ic|ALL_kver<nowiki>=</nowiki>}} parameter also matches the name of the custom kernel specified when copying the {{ic|bzImage}}:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your {{ic|/boot}} is on a filesystem which supports symlinks (i.e., not FAT32), copy {{ic|System.map}} to {{ic|/boot}}, appending your kernel's name to the destination file. Then create a symlink from {{ic|/boot/System.map}} to point to {{ic|/boot/System.map-YourKernelName}}:<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: {{ic|vmlinuz-YourKernelName}}<br />
* Initramfs: {{ic|Initramfs-YourKernelName.img}}<br />
* System Map: {{ic|System.map-YourKernelName}}<br />
* System Map kernel symlink<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Improving_performance/Boot_process&diff=440088Improving performance/Boot process2016-07-06T07:43:48Z<p>Voxadam: systemd-readahead has long since been abandoned and removed in its entirety from systemd. see: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg21693.html</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ar:Improve boot performance]]<br />
[[cs:Improve boot performance]]<br />
[[es:Improve boot performance]]<br />
[[it:Improve boot performance]]<br />
[[ja:ブートパフォーマンスの向上]]<br />
[[ru:Improve boot performance]]<br />
[[zh-cn:Improve boot performance]]<br />
{{Related articles start}}<br />
{{Related|Maximizing performance}}<br />
{{Related|Silent boot}}<br />
{{Related|Daemon}}<br />
{{Related|e4rat}}<br />
{{Related|Kexec}}<br />
{{Related articles end}}<br />
<br />
Improving the boot performance of a system can provide reduced boot wait times and a means to learn more about how certain system files and scripts interact with one another. This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.<br />
<br />
== Analyzing the boot process ==<br />
<br />
=== Using systemd-analyze ===<br />
<br />
[[systemd]] provides a tool called {{ic|systemd-analyze}} that can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. You can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly.<br />
<br />
To see how much time was spent in kernelspace and userspace on boot, simply use:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|If you boot via [[UEFI]] and use a boot loader which implements systemd's [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (which currently [[systemd-boot]] and [[GRUB]] do), ''systemd-analyze'' can additionally show you how much time was spent in the EFI firmware and the boot loader itself.}}<br />
<br />
To list the started unit files, sorted by the time each of them took to start up:<br />
<br />
$ systemd-analyze blame<br />
<br />
At some points of the boot process, things can not proceed until a given unit succeeds. To see which units find themselves at these critical points in the startup chain, do:<br />
<br />
$ systemd-analyze critical-chain<br />
<br />
You can also create an SVG file which describes your boot process graphically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
See {{ic|man systemd-analyze}} for details.<br />
<br />
=== Using systemd-bootchart ===<br />
<br />
Bootchart has been merged into '''systemd''' since Oct. 2012, and you can use it to boot just as you would with the original bootchart. Add this to your kernel line:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
After collecting a certain amount of data (configurable) the logging stops and a graph is generated from the logged information. This graph contains vital clues as to which resources are being used (by default I/O, CPU utilization and kernel init threads), in which order, and where possible problems exist in the startup sequence of the system. It is essentially a more detailed version of the systemd-analyze plot function.<br />
<br />
Bootchart graphs are by default written time-stamped in /run/log and saved to the journal with<br />
MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518. Journal field BOOTCHART= contains the bootchart in SVG format.<br />
<br />
See the [http://www.freedesktop.org/software/systemd/man/systemd-bootchart.html manpage] for more information.<br />
<br />
=== Using bootchart2 ===<br />
<br />
{{Merge|Bootchart#Running Bootchart2|different instructions from the main page}}<br />
<br />
You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the {{AUR|bootchart2-git}} package from [[AUR]] comes with an undocumented '''systemd''' service. After you've installed bootchart2 do:<br />
<br />
# systemctl enable bootchart2<br />
<br />
You can visualize the results by opening ''/var/log/bootchart.png'', or if you would like more features by launching <br />
<br />
$ pybootchartgui -i<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart2 documentation] for further details on using this version of bootchart.<br />
<br />
== Compiling a custom kernel ==<br />
<br />
Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64 bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. [[Kernel Compilation|Read more about compiling a kernel]].<br />
<br />
== Initramfs ==<br />
<br />
In a similar approach to [[#Compiling a custom kernel]], the initramfs can be slimmed down. A simple way is to include the [[mkinitcpio]] {{ic|autodetect}} hook. If you want to go further than that, see [[Minimal initramfs]].<br />
<br />
== Early start for services ==<br />
<br />
One central feature of systemd is [[D-Bus]] and socket activation. This causes services to be started when they are first accessed and is generally a good thing. However, if you know that a service (like [[UPower]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
# systemctl enable upower<br />
<br />
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
== Staggered spin-up ==<br />
<br />
Some hardware implements [[Wikipedia:Spin-up#Staggered spin-up|staggered spin-up]], which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:<br />
<br />
$ dmesg | grep SSS<br />
<br />
If it wasn't used during boot, there will be no output.<br />
<br />
To disable it, add {{ic|1=libahci.ignore_sss=1}} to the [[kernel line]].<br />
<br />
== Filesystem mounts ==<br />
<br />
Thanks to [[mkinitcpio]]'s {{ic|fsck}} hook, you can avoid a possibly costly remount of the root partition by changing {{ic|ro}} to {{ic|rw}} on the kernel line and removing it from {{ic|/etc/fstab}}. Options can be set with {{ic|1=rootflags=mount options...}} on the kernel line. Remember to remove the entry from your {{ic|/etc/fstab}} file, else the {{ic|systemd-remount-fs.service}} will continue to try to apply those settings. Alternatively, one could try to mask that unit.<br />
<br />
If btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, [[mkinitcpio]]'s {{ic|fsck}} hook can be removed. You may also want to mask the {{ic|systemd-fsck-root.service}}, or tell it not to fsck the root filesystem from the kernel command line using {{ic|fsck.mode&#61;skip}}. Without [[mkinitcpio]]'s {{ic|fsck}} hook, systemd will still fsck any relevant filesystems with the {{ic|systemd-fsck@.service}}<br />
<br />
You can also remove API filesystems from {{ic|/etc/fstab}}, as systemd will mount them itself (see {{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.<br />
<br />
Other filesystems like {{ic|/home}} can be mounted with custom mount units. Adding {{ic|noauto,x-systemd.automount}} to mount options will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.<br />
<br />
{{Note|<br />
* This will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.<br />
* If the system is installed into a [[Btrfs]] subvolume (specifically: the root directory {{ic|/}} itself is a subvolume) and {{ic|/home}} is a separate file system, you may also want to prevent the creation of a {{ic|/home}} subvolume. Mask the {{ic|home.conf}} tmpfile: {{ic|ln -s /dev/null /etc/tmpfiles.d/home.conf}}.<br />
}}<br />
<br />
== Less output during boot ==<br />
<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
== Suspend to RAM ==<br />
<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend and hibernate#Suspend to RAM|suspending your system to RAM]] instead.</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Firewalls&diff=437580Firewalls2016-06-07T07:45:42Z<p>Voxadam: </p>
<hr />
<div>[[Category:Firewalls]]<br />
[[es:Firewalls]]<br />
[[fa:Firewalls]]<br />
[[it:Firewalls]]<br />
[[ja:ファイアウォール]]<br />
[[sr:Firewalls]]<br />
[[sv:Brandväggar]]<br />
A firewall is a system designed to prevent unauthorized access to or from a private network (which could be just one machine). Firewalls can be implemented in only hardware or software, or a combination of both. Firewalls are frequently used to prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets. All messages entering or leaving the intranet pass through the firewall, which examines each message and allows, proxys, or denies the traffic based on specified security criteria.<br />
<br />
The firewalls listed in this article are overwhelmingly based on the [[iptables]] program. Consider configuring the iptables process yourself according to its wiki page (listed below) to keep to the [[Arch_Linux#Principles|"The Arch Way"]].<br />
<br />
There are many posts on the forums about different firewall apps and scripts so here they all are condensed into one page - please add your comments about each firewall, especially ease of use and a security check at [http://www.grc.com/x/ne.dll?bh0bkyd2 Shields Up].<br />
<br />
{{Note|Checks at Shields Up are only a valid measure of your router should you have one in the LAN. To accurately evaluate a software firewall, one needs to directly connect the box to the cable modem.}}<br />
<br />
== Firewall guides and tutorials ==<br />
<br />
* [[Simple stateful firewall]] - Setting up a comprehensive firewall with [[iptables]].<br />
* [[Uncomplicated Firewall]] - the wiki page for the simple [[iptables]] frontend, {{Pkg|ufw}}, provides a nice tutorial for a basic configuration.<br />
* [[Router]] Setup Guide - A tutorial for turning a computer into an [[Wikipedia:Router (computing)|internet gateway/router]]. It focuses on [[security]] and configuring your gateway to have as few insecure holes to the internet as possible.<br />
<br />
==== External firewall tutorials ====<br />
<br />
* http://www.frozentux.net/documents/iptables-tutorial/ A complete and simple tutorial to [[iptables]].<br />
* http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/html_single/IP-Masquerade-HOWTO.html Masq is a form of Network Address Translation or NAT that allows internally networked computers that do not have one or more registered Internet IP addresses to have the ability to communicate to the Internet via your Linux boxes single Internet IP address.<br />
* http://tldp.org/HOWTO/Masquerading-Simple-HOWTO/ Masquerading, [[Wikipedia:Proxy server#Transparent proxy|transparent proxying]], [[Wikipedia:Port forwarding|port forwarding]], and other forms of [[Wikipedia:Network address translation|Network Address Translations]] with the 2.4 Linux Kernels.<br />
<br />
== iptables ==<br />
<br />
The Linux kernel includes [[iptables]] as a built-in firewall solution. Configuration may be managed directly through the userspace utilities or by installing one of several GUI configuration tools.<br />
<br />
=== Console frontends ===<br />
<br />
* {{App|Arno's firewall|Secure firewall for both single and multi-homed machines. Very easy to configure, handy to manage and highly customizable. Supports: NAT and SNAT, port forwarding, ADSL ethernet modems with both static and dynamically assigned IPs, MAC address filtering, stealth port scan detection, DMZ and DMZ-2-LAN forwarding, protection against SYN/ICMP flooding, extensive user definable logging with rate limiting to prevent log flooding, all IP protocols and VPNs such as IPsec, plugin support to add extra features.|http://rocky.eld.leidenuniv.nl/|{{AUR|arno-iptables-firewall}}}}<br />
* {{App|ferm|Tool to maintain complex firewalls, without having the trouble to rewrite the complex rules over and over again. It allows the entire firewall rule set to be stored in a separate file, and to be loaded with one command. The firewall configuration resembles structured programming-like language, which can contain levels and lists.|http://ferm.foo-projects.org/|{{Pkg|ferm}}}}<br />
* {{App|Firehol|Language to express firewalling rules, not just a script that produces some kind of a firewall. It makes building even sophisticated firewalls easy - the way you want it.|http://firehol.sourceforge.net/|{{AUR|firehol}}}}<br />
* {{App|Firetable|Firewall with "human readable" syntax.|http://projects.leisink.net/Firetable|{{AUR|firetable}}}}<br />
* {{App|[[Shorewall]]|High-level tool for configuring Netfilter. You describe your firewall/gateway requirements using entries in a set of configuration files.|http://www.shorewall.net/|{{Pkg|shorewall}}}}<br />
* {{App|[[ufw]]|Simple front-end for iptables.|https://launchpad.net/ufw|{{Pkg|ufw}}}}<br />
* {{App|[[PeerGuardian Linux]]|Privacy oriented firewall application. It blocks connections to and from hosts specified in huge block lists (thousands or millions of IP ranges).|http://sourceforge.net/projects/peerguardian/|{{AUR|pgl-cli}}}}<br />
* {{App|Vuurmuur|Powerful firewall manager. It has a simple and easy to learn configuration that allows both simple and complex configurations. The configuration can be fully configured through an {{Pkg|ncurses}} GUI, which allows secure remote administration through SSH or on the console. Vuurmuur supports traffic shaping, has powerful monitoring features, which allow the administrator to look at the logs, connections and bandwidth usage in realtime.|http://www.vuurmuur.org/|{{AUR|vuurmuur}}}}<br />
<br />
=== Graphic frontends ===<br />
<br />
* {{App|Firestarter|Good GUI for iptables writen on GTK2, it has the ability to use both white and black lists for regulating traffic, it is very simple and easy to use, with good documentation available on their website.|http://www.fs-security.com/|{{AUR|Firestarter}}}}<br />
* {{App|Firewall Builder|GUI firewall configuration and management tool that supports iptables (netfilter), ipfilter, pf, ipfw, Cisco PIX (FWSM, ASA) and Cisco routers extended access lists. The program runs on Linux, FreeBSD, OpenBSD, Windows and Mac OS X and can manage both local and remote firewalls.|http://www.fwbuilder.org/|{{Pkg|fwbuilder}}}}<br />
* {{App|firewalld|Daemon and graphical interface for configuring network and firewall zones as well as setting up and configuring firewall rules.|https://fedoraproject.org/wiki/FirewallD|{{Pkg|firewalld}}}}<br />
* {{App|[[Uncomplicated_Firewall#Gufw|Gufw]]|GTK-based front-end to {{Pkg|ufw}} which happens to be a CLI front-end to iptables (gufw->ufw->iptables), is super easy and super simple to use.|http://gufw.org/|{{Pkg|gufw}}}}<br />
* {{App|KMyFirewall|KDE3 GUI for iptables. Firewall editing capabilities are simple enough to use to be suitable for beginners, but also allow for sophisticated tweaking of the firewall settings.|http://kmyfirewall.sourceforge.net/|{{AUR|kmyfirewall}}{{Broken package link|{{aur-mirror|kmyfirewall}}}}}}<br />
* {{App|[[PeerGuardian Linux]]|Privacy oriented firewall application. It blocks connections to and from hosts specified in huge block lists (thousands or millions of IP ranges).|http://sourceforge.net/projects/peerguardian/|{{AUR|pgl}}}}<br />
* {{App|[[Uncomplicated_Firewall#kcm-ufw|kcm-ufw]]|KDE alternative to Gufw.|http://kde-apps.org/content/show.php?content&#61;137789|{{AUR|kcm-ufw}}}}<br />
<br />
== nftables ==<br />
<br />
[[nftables]] is a netfilter project that aims to replace the existing ip-, ip6-, arp-, and ebtables framework. It is supposed to replace iptables one day.<br />
<br />
== Other ==<br />
<br />
* {{App|[[Wikipedia:EtherApe|EtherApe]]|Graphical network monitor for various OSI layers and protocols.|http://etherape.sourceforge.net/|{{Pkg|etherape}}}}<br />
* {{App|[[Fail2ban]]|Bans IPs after too many failed authentification attempts against common daemons.|http://www.fail2ban.org/|{{Pkg|fail2ban}}}}<br />
<br />
== See Also ==<br />
<br />
* http://wiki.debian.org/Firewalls - Debian Wiki's list of firewalls</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Talk:Xdg_user_directories&diff=436427Talk:Xdg user directories2016-05-26T20:52:23Z<p>Voxadam: Voxadam moved page Talk:Xdg user directories to Talk:XDG User Directories</p>
<hr />
<div>#REDIRECT [[Talk:XDG User Directories]]</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Talk:XDG_user_directories&diff=436426Talk:XDG user directories2016-05-26T20:52:23Z<p>Voxadam: Voxadam moved page Talk:Xdg user directories to Talk:XDG User Directories</p>
<hr />
<div>== CACHE, CONFIG, DATA directories ==<br />
<br />
How to these XDG specification directories fit in?:<br />
<br />
export XDG_CACHE_HOME="${HOME}/.cache"<br />
export XDG_CONFIG_HOME="${HOME}/.config"<br />
export XDG_DATA_HOME="${HOME}/.config"<br />
<br />
The above block is something I saw written into a {{ic|~/.bashrc}}. How do they fit in?<br />
<br />
I've tried typing {{ic|env}} doesn't list them, yet I know applications use them. Are they hard-coded in applications? By the way, {{ic|XDG_DATA_HOME}} should probably by default be {{ic|$HOME/.local/share}} as talked about [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html here].<br />
<br />
-- [[User:Gen2ly|Gen2ly]] ([[User talk:Gen2ly|talk]]) 17:29, 14 September 2014 (UTC)<br />
<br />
:The difference is between [http://freedesktop.org/wiki/Software/xdg-user-dirs/ xdg-user-dirs] (note that it is in Software section) and [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG Base Directory Specification]. From the latter:<br />
::''"$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used."''<br />
:Hence the applications are expected to set the default value by themselves. Some applications use third-party libraries, and some even hard-code {{ic|$HOME/.config/}} (or something else) and deviate from the specification.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:53, 14 September 2014 (UTC)</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Xdg_user_directories&diff=436425Xdg user directories2016-05-26T20:52:23Z<p>Voxadam: Voxadam moved page Xdg user directories to XDG User Directories</p>
<hr />
<div>#REDIRECT [[XDG User Directories]]</div>Voxadamhttps://wiki.archlinux.org/index.php?title=XDG_user_directories&diff=436424XDG user directories2016-05-26T20:52:23Z<p>Voxadam: Voxadam moved page Xdg user directories to XDG User Directories</p>
<hr />
<div>[[Category:Desktop environments]]<br />
[[ja:Xdg ユーザーディレクトリ]]<br />
{{Related articles start}}<br />
{{Related|xdg-menu}}<br />
{{Related|Default applications}}<br />
{{Related|XDG Base Directory support}}<br />
{{Related articles end}}<br />
User directories are a set of common user directories located within the {{ic|$HOME}} directory, including {{ic|Documents}}, {{ic|Downloads}}, {{ic|Music}}, and {{ic|Desktop}}. Identified by unique icons within a file manager, they will commonly be automatically sourced by numerous programs and applications. {{pkg|xdg-user-dirs}} is a program that will automatically generate these directories. See the [https://www.freedesktop.org/wiki/Software/xdg-user-dirs freedesktop.org] website for further information.<br />
<br />
{{Tip|This program will be especially helpful for those who wish to use a file manager to manage their desktop for a [[Window manager]] such as [[Openbox]], as it will also automatically create a {{ic|~/Desktop}} directory.}}<br />
<br />
== Installation ==<br />
<br />
{{Accuracy|Installing the package does not seem to be necessary in order to e.g. prevent applications from creating directories with unwanted names: creating the files in {{ic|~/.config}} manually should be equally effective. This should be clarified here, but the whole article might need a review.}}<br />
<br />
[[Install]] the {{pkg|xdg-user-dirs}} package.<br />
<br />
== Creating default directories ==<br />
<br />
{{Accuracy|This needs a technical review, as e.g. {{ic|/etc/xdg/user-dirs.defaults}} is installed by the package, obviously not created by a command run by a normal user.}}<br />
<br />
To create a full suite of localized default user directories within the {{ic|$HOME}} directory, enter the following command:<br />
<br />
$ xdg-user-dirs-update<br />
<br />
{{Tip|To force the creation of English-named directories, {{ic|1=LC_ALL=C xdg-user-dirs-update}} can be used.}}<br />
<br />
When executed, it will also automatically:<br />
<br />
* Create a local {{ic|~/.config/user-dirs.dirs}} configuration file: used by applications to find and use home directories specific to an account.<br />
* Create a global {{ic|/etc/xdg/user-dirs.defaults}} configuration file: used by applications to find and use home directories generally.<br />
* Create a local {{ic|~/.config/user-dirs.locale}} configuration file: used to set the language according to the locale in use.<br />
<br />
== Creating custom directories ==<br />
<br />
Both the local {{ic|~/.config/user-dirs.dirs}} and global {{ic|/etc/xdg/user-dirs.defaults}} configuration files use the following environmental variable format to point to user directories: {{ic|1=XDG_DIRNAME_DIR="$HOME/directory_name}}" An example configuration file will/may likely look like this (these are all the template directories):<br />
<br />
XDG_DESKTOP_DIR="$HOME/Desktop"<br />
XDG_DOCUMENTS_DIR="$HOME/Documents"<br />
XDG_DOWNLOAD_DIR="$HOME/Downloads"<br />
XDG_MUSIC_DIR="$HOME/Music"<br />
XDG_PICTURES_DIR="$HOME/Pictures"<br />
XDG_PUBLICSHARE_DIR="$HOME/Public"<br />
XDG_TEMPLATES_DIR="$HOME/.Templates"<br />
XDG_VIDEOS_DIR="$HOME/Videos"<br />
<br />
As {{pkg|xdg-user-dirs}} will source the local configuration file to point to the appropriate user directories, it is therefore possible to specify custom folders. For example, if a custom folder for the {{ic|XDG_DOWNLOAD_DIR}} variable has named {{ic|1=$HOME/Internet}} in {{ic|~/.config/user-dirs.dirs}} any application that uses this variable will use this directory.<br />
<br />
{{Note|Like with many configuration files, local settings override global settings. It will also be necessary to create any new custom directories.}}<br />
<br />
Alternatively, it is also possible to specify custom folders using the command line. For example, the following command will produce the same results as the above configuration file edit:<br />
<br />
$ xdg-user-dirs-update --set DOWNLOAD ~/Internet<br />
<br />
== Querying configured directories ==<br />
<br />
Once set, any user directory can be viewed with {{pkg|xdg-user-dirs}}. For example, the following command will specify the location of the {{ic|Templates}} directory, which of course corresponds to the {{ic|XDG_TEMPLATES_DIR}} variable in the local configuration file:<br />
<br />
$ xdg-user-dir TEMPLATES</div>Voxadamhttps://wiki.archlinux.org/index.php?title=Tmux&diff=412311Tmux2015-12-14T22:59:19Z<p>Voxadam: /* Changing the configuration with tmux started */</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
[[es:Tmux]]<br />
[[ja:Tmux]]<br />
[[ru:Tmux]]<br />
[[tr:Tmux]]<br />
[[zh-CN:Tmux]]<br />
{{Related articles start}}<br />
{{Related|GNU Screen}}<br />
{{Related articles end}}<br />
<br />
[http://tmux.github.io/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is a BSD-licensed alternative to [[GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [https://raw.githubusercontent.com/tmux/tmux/master/FAQ tmux FAQ page].<br />
<br />
== Installation ==<br />
[[Install]] the {{Pkg|tmux}} package.<br />
<br />
== Configuration ==<br />
A user-specific configuration file should be located at {{ic|~/.tmux.conf}}, while a global configuration file should be located at {{ic|/etc/tmux.conf}}. Default configuration files can be found in {{Ic|/usr/share/tmux/}}. <br />
<br />
=== Key bindings ===<br />
<br />
By default, command key bindings are prefixed by {{Ic|Ctrl-b}}. For example, to vertically split a window type {{Ic|Ctrl-b+%}}.<br />
<br />
After splitting a window into multiple panes, a pane can be resized by the hitting prefix key (e.g. {{Ic|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic [[screen]] key bindings copy {{ic|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{ic|tmux.conf}}. For example, the default prefix binding of {{Ic|Ctrl-b}} can be changed to {{Ic|Ctrl-a}} by adding the following commands in your configuration file:<br />
<br />
{{bc|<br />
unbind C-b<br />
set -g prefix C-a<br />
bind C-a send-prefix<br />
}}<br />
<br />
{{Tip|Quote special characters to use them as prefix. You may also use {{ic|Alt}} (called Meta) instead of {{ic|Ctrl}}. For example: {{ic|set -g prefix m-'\'}}}}<br />
<br />
Additional ways to move between windows include the following:<br />
<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
Tmux has a find-window option & key binding to ease navigation of many windows:<br />
<br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
==== Copy Mode ====<br />
<br />
A tmux window may be in one of several modes. The default permits direct access to the terminal attached to the window; the other is copy mode. Once in copy mode you can navigate the buffer including scrolling the history. Use vi or emacs-style key bindings in copy mode. The default is emacs, unless VISUAL or EDITOR contains ‘vi’<br />
<br />
To enter copy mode do the following:<br />
<br />
Ctrl-b [<br />
<br />
You can navigate the buffer as you would in your default editor.<br />
<br />
To quit copy mode, use one of the following keybindings:<br />
<br />
vi mode:<br />
q<br />
emacs mode:<br />
Esc<br />
<br />
=== Browsing URLs ===<br />
To browse URLs inside tmux you must have {{AUR|urlview}} installed and configured.<br />
<br />
Inside a new terminal:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e urlview /tmp/tmux-buffer"<br />
<br />
Or inside a new tmux window (no new terminal needed):<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; new-window -n "urlview" '$SHELL -c "urlview < /tmp/tmux-buffer"'<br />
<br />
=== Setting the correct term ===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in {{ic|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
If you enable xterm-keys in your {{ic|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{ic|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
=== Other Settings ===<br />
Set scrollback to 10000 lines with <br />
set -g history-limit 10000<br />
<br />
=== Autostart with systemd ===<br />
<br />
There are some notable advantages to starting a tmux server at startup.<br />
Notably, when you start a new tmux session, having the service already running reduces any delays in the startup.<br />
<br />
Furthermore, any customization attached to your tmux session will be retained and your tmux session can be made to persist even if you have never logged in, if you have some reason to do that (like a heavily scripted tmux configuration or shared user tmux sessions).<br />
<br />
The service below starts ''tmux'' for the specified user (i.e. start with {{ic|tmux@''username''.service}}):<br />
<br />
{{hc|/etc/systemd/system/tmux@.service|<nowiki><br />
[Unit]<br />
Description=Start tmux in detached session<br />
<br />
[Service]<br />
Type=forking<br />
User=%I<br />
ExecStart=/usr/bin/tmux new-session -s %u -d<br />
ExecStop=/usr/bin/tmux kill-session -t %u<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Tip|You may want to add {{ic|1=WorkingDirectory=''custom_path''}} to customize working directory.}}<br />
<br />
Alternatively, you can place this file within your [[systemd/User]] directory (without {{ic|1=User=%I}}), for example {{ic|~/.config/systemd/user/tmux.service}}. This way the tmux service will start when you log in.<br />
<br />
== Session initialization ==<br />
You can have tmux open a session with preloaded windows by including those details in your {{ic|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{ic|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
== Troubleshooting ==<br />
<br />
=== Scrolling issues ===<br />
If you have issues scrolling with Shift-Page Up/Down in your terminal, the following will remove the smcup and rmcup capabilities for any term that reports itself as anything beginning with {{ic|xterm}}:<br />
<br />
set -ga terminal-overrides ',xterm*:smcup@:rmcup@'<br />
<br />
This tricks the terminal emulator into thinking Tmux is a full screen application like pico or mutt[http://superuser.com/questions/310251/use-terminal-scrollbar-with-tmux], which will make the scrollback be recorded properly. Beware however, it will get a bit messed up when switching between windows/panes. Consider using Tmux's native scrollback instead.<br />
=== Mouse scrolling ===<br />
{{Note|This interferes with selection buffer copying and pasting. To copy/paste to/from the selection buffer hold the shift key.}}<br />
If you want to scroll with your mouse wheel, ensure mode-mouse is on in .tmux.conf<br />
set -g mouse on<br />
<br />
You can set scroll History with:<br />
set -g history-limit 30000<br />
<br />
=== Fix reverse-video/italic mode in urxvt ===<br />
<br />
{{out of date|You can now use the tmux or tmux-256color terminfo by putting the following line in your tmux.conf {{ic|set -g default-terminal "tmux-256color"}}}}<br />
<br />
If your reverse-video and italic modes are reversed, you may follow these instructions. This happens for example in vim when italics are replaced by highlighting, or in less when the search highlighting is replaced by italics. This is because the screen terminfo doesn't define italics, and the italics escape of urxvt happens to be the standout escape defined in the terminfo. In this solution, you may replace {{ic|1=screen_terminfo="screen"}} by {{ic|1=screen_terminfo="screen-256color"}}.<br />
<br />
mkdir $HOME/.terminfo/<br />
screen_terminfo="screen"<br />
<br />
Create a new terminfo adding the italic escape code:<br />
<br />
infocmp "$screen_terminfo" | sed \<br />
-e 's/^screen[^|]*|[^,]*,/screen-it|screen with italics support,/' \<br />
-e 's/%?%p1%t;3%/%?%p1%t;7%/' \<br />
-e 's/smso=[^,]*,/smso=\\E[7m,/' \<br />
-e 's/rmso=[^,]*,/rmso=\\E[27m,/' \<br />
-e '$s/$/ sitm=\\E[3m, ritm=\\E[23m,/' > /tmp/screen.terminfo<br />
<br />
Compile this terminfo:<br />
<br />
tic /tmp/screen.terminfo<br />
<br />
Then, you must add the following line in your tmux.conf. If you already defined {{ic|1=default-terminal}}, just replace it.<br />
<br />
set -g default-terminal "screen-it"<br />
<br />
The source of this solution can be found at [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ], in the section entitled "vim displays reverse video instead of italics, while less displays italics (or just regular text) instead of reverse. What's wrong?".<br />
<br />
=== Shift+F6 not working in Midnight Commander ===<br />
<br />
If the {{ic|Shift+F6}} key combination is not working with either {{ic|1=TERM=screen}} or {{ic|1=TERM=screen-256color}}, then from inside tmux, run this command:<br />
infocmp > screen (or screen-256color)<br />
<br />
Open the file in a text editor, and add the following to the bottom of that file:<br />
kf16=\E[29~,<br />
<br />
Then compile the file with {{ic|tic}}. The keys should be working now.<br />
<br />
== X clipboard integration ==<br />
<br />
{{Tip|The tmux plugin [https://github.com/tmux-plugins/tmux-yank tmux-yank] provides similar functionality.}}<br />
<br />
It is possible to copy tmux selection to X clipboard (and to X primary/secondary selection) and in reverse direction. The following tmux config file snippet effectively integrates X clipboard/selection with the current tmux selection using the program {{Pkg|xsel}}:<br />
<br />
# Emacs style<br />
bind-key -t emacs-copy M-w copy-pipe "xsel -i -p -b"<br />
bind-key C-y run "xsel -o | tmux load-buffer - ; tmux paste-buffer"<br />
<br />
# Vim style<br />
bind-key -t vi-copy y copy-pipe "xsel -i -p -b"<br />
bind-key p run "xsel -o | tmux load-buffer - ; tmux paste-buffer"<br />
<br />
{{pkg|xclip}} could also be used for that purpose, unlike xsel it works better on printing raw bitstream that doesn't fit the current locale. Nevertheless, it is neater to use <code>xsel</code> instead of <code>xclip</code>, because xclip does not close STDOUT after it has read from tmux's buffer. As such, tmux doesn't know that the copy task has completed, and continues to wait for xclip's termination, thereby rendering tmux unresponsive. A workaround is to redirect <code>STDOUT</code> of <code>xclip</code> to <code>/dev/null</code>, like in the following:<br />
<br />
# Vim style<br />
bind-key -t vi-copy y copy-pipe "xclip -i -sel clip > /dev/null"<br />
bind-key p run "xclip -o -sel clip | tmux load-buffer -"<br />
<br />
=== Urxvt middle click ===<br />
<br />
{{Note|To use this, you need to enable mouse support}}<br />
<br />
There is an unofficial perl extension (mentioned in the official [http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/FAQ FAQ]) to enable copying/pasting in and out of urxvt with tmux via Middle Mouse Clicking.<br />
<br />
First, you will need to download the perl script and place it into urxvts perl lib:<br />
<br />
{{bc|wget http://anti.teamidiot.de/static/nei/*/Code/urxvt/osc-xterm-clipboard<br />
mv osc-xterm-clipboard /usr/lib/urxvt/perl/|<br />
}}<br />
<br />
You will also need to enable that perl script in your .Xdefaults:<br />
<br />
{{hc|~/.Xdefaults|<br />
...<br />
*URxvt.perl-ext-common: osc-xterm-clipboard<br />
...<br />
}}<br />
<br />
Next, you want to tell tmux about the new function and enable mouse support (if you haven't already):<br />
<br />
{{hc|~/.tmux.conf|<br />
...<br />
set-option -ga terminal-override ',rxvt-uni*:XT:Ms<nowiki>=</nowiki>\E]52;%p1%s;%p2%s\007'<br />
set -g mouse on<br />
...<br />
}}<br />
<br />
That's it. Be sure to end all instances of tmux before trying the new MiddleClick functionality.<br />
<br />
While in tmux, Shift+MiddleMouseClick will paste the clipboard selection while just MiddleMouseClick will paste your tmux buffer.<br />
Outside of tmux, just use MiddleMouseClick to paste your tmux buffer and your standard Ctrl-c to copy.<br />
<br />
== Tips and tricks ==<br />
=== Start tmux with default session layout ===<br />
To setup your default Tmux session layout, you install {{AUR|tmuxinator}} from [[AUR]]. Test your installation with<br />
<br />
tmuxinator doctor<br />
<br />
==== Get the default layout values ====<br />
Start Tmux as usual and configure your windows and panes layout as you like. When finished, get the current layout values by executing (while you are still within the current Tmux session)<br />
<br />
tmux list-windows<br />
<br />
The output may look like this (two windows with 3 panes and 2 panes layout)<br />
<br />
0: default* (3 panes) [274x83] [layout 20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}] @2 (active)<br />
1: remote- (2 panes) [274x83] [layout e3d3,274x83,0,0[274x41,0,0,4,274x41,0,42,7]] @3 <br />
<br />
The Interesting part you need to copy for later use begins after '''[layout...''' and excludes '''... ] @2 (active)'''. For the first window layout you need to copy e.g. '''20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}'''<br />
<br />
==== Define the default tmux layout ====<br />
<br />
Knowing this, you can exit the current tmux session. Following this, you create your default Tmux session layout by editing Tmuxinator's config file (Don't copy the example, get your layout values as described above)<br />
<br />
{{hc|~/.tmuxinator/default.yml|<nowiki><br />
name: default<br />
root: ~/<br />
windows:<br />
- default:<br />
layout: 20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}<br />
panes:<br />
- clear<br />
- vim<br />
- clear && emacs -nw<br />
- remote:<br />
layout: 24ab,274x83,0,0{137x83,0,0,3,136x83,138,0,4}<br />
panes:<br />
- <br />
- <br />
</nowiki>}}<br />
<br />
The example defines two windows named "default" and "remote". With your determined layout values. For each pane you have to use at least one {{ic|-}} line. Within the first window panes you start the commandline "clear" in pane one, "vim" in pane two and "clear && emacs -nw" executes two commands in pane three on each Tmux start. The second window layout has two panes without defining any start commmands.<br />
<br />
Test the new default layout with (yes, it is "mux"):<br />
<br />
mux default<br />
<br />
==== Autostart tmux with default tmux layout ====<br />
<br />
If you like to start your terminal session with your default Tmux session layout edit<br />
{{hc|~/.bashrc|<nowiki><br />
if [ -z "$TMUX" ]; then<br />
mux default <br />
fi <br />
</nowiki>}}<br />
<br />
====Alternate approach for default session====<br />
Instead of using the above method, one can just write a bash script that when run, will create the default session and attach to it.<br />
Then you can execute it from a terminal to get the pre-designed configuration in that terminal<br />
<br />
#!/bin/bash<br />
tmux new-session -d -n WindowName Command<br />
tmux new-window -n NewWindowName<br />
tmux split-window -v<br />
tmux selectp -t 1<br />
tmux split-window -h<br />
tmux selectw -t 1<br />
tmux -2 attach-session -d<br />
<br />
===Start tmux in urxvt===<br />
Use this command to start urxvt with a started tmux session. I use this with the exec command from my .ratpoisonrc file.<br />
{{bc|<nowiki>urxvt -e bash -c "tmux -q has-session && exec tmux attach-session -d || exec tmux new-session -n$USER -s$USER@$HOSTNAME"</nowiki>}}<br />
<br />
=== Start tmux on every shell login ===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# If not running interactively, do not do anything<br />
[[ $- != *i* ]] && return<br />
[[ -z "$TMUX" ]] && exec tmux<br />
</nowiki>}}<br />
<br />
{{note|This snippet ensures that tmux is not launched inside of itself (something tmux usually already checks for anyway). tmux sets $TMUX to the socket it is using whenever it runs, so if $TMUX isn't set or is length 0, we know we aren't already running tmux.}}<br />
<br />
Add the following snippet to start only one session (unless you start some manually), on login, try attach at first, only create a session if no tmux is running.<br />
<br />
{{bc|<nowiki><br />
# TMUX<br />
if which tmux >/dev/null 2>&1; then<br />
#if not inside a tmux session, and if no session is started, start a new session<br />
test -z "$TMUX" && (tmux attach || tmux new-session)<br />
fi<br />
</nowiki>}}<br />
<br />
The following snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
{{bc|<nowiki><br />
# TMUX<br />
if which tmux >/dev/null 2>&1; then<br />
# if no session is started, start a new session<br />
test -z ${TMUX} && tmux<br />
<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
Another possibility is to try to attach to existing deattached session or start a new session:<br />
<br />
{{bc|<nowiki><br />
if [[ -z "$TMUX" ]] ;then<br />
ID="`tmux ls | grep -vm1 attached | cut -d: -f1`" # get the id of a deattached session<br />
if [[ -z "$ID" ]] ;then # if not available create a new one<br />
tmux new-session<br />
else<br />
tmux attach-session -t "$ID" # if available attach to it<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. (i. e. urxvt -e tmux)}}<br />
<br />
=== Start a non-login shell ===<br />
<br />
Tmux starts a [http://unix.stackexchange.com/questions/38175 login shell] [http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/5997 by default], which may result in multiple negative side effects:<br />
<br />
* Users of [[Wikipedia:fortune (Unix)|fortune]] may notice that quotes are printed when creating a new panel.<br />
* The configuration files for login shells such as {{ic|~/.profile}} are interpreted each time a new panel is created, so commands intended to be run on session initialization (e.g. setting audio level) are executed.<br />
<br />
To disable this behaviour, add to {{ic|~/.tmux.conf}}:<br />
<br />
set -g default-command "${SHELL}"<br />
<br />
=== Use tmux windows like tabs ===<br />
<br />
The following settings added to {{ic|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{ic|Ctrl+d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
=== Clients simultaneously interacting with various windows of a session ===<br />
<br />
In [http://mutelight.org/articles/practical-tmux Practical Tmux], Brandur Leach writes:<br />
<br />
: Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
: This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
The script “{{Ic|tmx}}” below implements this — the version here is slightly modified to execute “{{Ic|tmux new-window}}” if “1” is its second parameter. Invoked as {{Ic|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise a new “client” session linked to the base, optionally add a new window and attach, setting it to kill itself once it turns “zombie”.<br />
<br />
{{hc|tmx|2=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
echo "Launching copy of base session $base_session ..."<br />
# Session id is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session & kill it once orphaned<br />
tmux attach-session -t $session_id \; set-option destroy-unattached<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{ic|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
An alternative taken from [http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/2632] is to put the following ~/.bashrc:<br />
<br />
{{hc|.bashrc|2=<nowiki><br />
function rsc() {<br />
CLIENTID=$1.`date +%S`<br />
tmux new-session -d -t $1 -s $CLIENTID \; set-option destroy-unattached \; attach-session -t $CLIENTID<br />
}<br />
<br />
function mksc() {<br />
tmux new-session -d -s $1<br />
rsc $1<br />
}<br />
</nowiki>}}<br />
<br />
Citing the author:<br />
<br />
: "mksc foo" creates a always detached permanent client named "foo". It also calls "rsc foo" to create a client to newly created session. "rsc foo" creates a new client grouped by "foo" name. It has destroy-unattached turned on so when I leave it, it kills client.<br />
: Therefore, when my computer looses network connectivity, all "foo.something" clients are killed while "foo" remains. I can then call "rsc foo" to continue work from where I stopped.<br />
<br />
=== Correct the TERM variable according to terminal type ===<br />
Instead of [[#Setting_the_correct_term|setting a fixed TERM variable in tmux]], it is possible to set the proper TERM (either {{ic|screen}} or {{ic|screen-256color}}) according to the type of your terminal emulator:<br />
<br />
{{hc|~/.tmux.conf|<br />
## set the default TERM<br />
set -g default-terminal screen<br />
<br />
## update the TERM variable of terminal emulator when creating a new session or attaching a existing session<br />
set -g update-environment 'DISPLAY SSH_ASKPASS SSH_AGENT_PID SSH_CONNECTION WINDOWID XAUTHORITY TERM'<br />
## determine if we should enable 256-colour support<br />
if "[[ ${TERM} =~ 256color || ${TERM} == fbterm ]]" 'set -g default-terminal screen-256color'<br />
}}<br />
<br />
{{hc|1=~/.zshrc|2=<br />
## workaround for handling TERM variable in multiple tmux sessions properly from http://sourceforge.net/p/tmux/mailman/message/32751663/ by Nicholas Marriott<br />
if [[ -n ${TMUX} && -n ${commands[tmux]} ]];then<br />
case $(tmux showenv TERM 2>/dev/null) in<br />
*256color) ;&<br />
TERM=fbterm)<br />
TERM=screen-256color ;;<br />
*)<br />
TERM=screen<br />
esac<br />
fi<br />
}}<br />
<br />
=== Reload an updated configuration without restarting tmux ===<br />
<br />
By default tmux reads {{ic|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{ic|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
You can also do ^: and type :<br />
source .tmux.conf<br />
<br />
===Template script to run program in new session resp. attach to existing one===<br />
<br />
This script checks for a program presumed to have been started by a previous run of itself. Unless found it creates a new tmux session and attaches to a window named after and running the program. If however the program was found it merely attaches to the session and selects the window.<br />
<br />
#!/bin/bash<br />
<br />
PID=$(pidof $1)<br />
<br />
if [ -z "$PID" ]; then<br />
tmux new-session -d -s main ;<br />
tmux new-window -t main -n $1 "$*" ;<br />
fi<br />
tmux attach-session -d -t main ;<br />
tmux select-window -t $1 ;<br />
exit 0<br />
<br />
A derived version to run ''irssi'' with the ''nicklist'' plugin can be found on [[Irssi#irssi_with_nicklist_in_tmux|its ArchWiki page]].<br />
<br />
=== Terminal emulator window titles ===<br />
If you SSH into a host in a tmux window, you'll notice the window title of your terminal emulator remains to be {{ic|user@localhost}} rather than {{ic|user@server}}. To allow the title bar to adapt to whatever host you connect to, set the following in {{ic|~/.tmux.conf}}<br />
<br />
set -g set-titles on<br />
set -g set-titles-string "#T"<br />
<br />
For {{ic|set-titles-string}}, {{ic|#T}} will display {{ic|user@host:~}} and change accordingly as you connect to different hosts.<br />
<br />
=== Automatic layouting ===<br />
When creating new splits or destroying older ones the currently selected layout isn't applied. To fix that, add following binds which will apply the currently selected layout to new or remaining panes:<br />
<br />
bind-key -n M-c kill-pane \; select-layout<br />
bind-key -n M-n split-window \; select-layout<br />
<br />
=== Vim friendly configuration ===<br />
<br />
See [https://gist.github.com/anonymous/6bebae3eb9f7b972e6f0] for a configuration friendly to [[vim]] users.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 BBS topic]<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison]<br />
* [https://github.com/Lokaltog/powerline powerline], a dynamic statusbar for tmux<br />
* [https://github.com/tmux-plugins Plugins for tmux]<br />
<br />
'''Tutorials'''<br />
<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux]<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux FAQ (OpenBSD)]<br />
* [http://www.openbsd.org/cgi-bin/man.cgi?query=tmux man page (OpenBSD)]<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] and [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2]</div>Voxadamhttps://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=404281XDG Base Directory2015-10-12T00:42:42Z<p>Voxadam: /* Exceptions */</p>
<hr />
<div>[[Category:Dotfiles]]<br />
{{Related articles start}}<br />
{{Related|dotfiles}}<br />
{{Related|Xdg user directories}}<br />
{{Related articles end}}<br />
This article exists to catalog the growing set of software using the [http://standards.freedesktop.org/basedir-spec/latest/ XDG Base Directory Specification] introduced in 2003. This is here to demonstrate the viability of this specification by listing commonly found dotfiles and their support status. For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.<br />
<br />
The workarounds will be limited to anything not involving patching the source, executing code stored in [[environment variable]]s or compile-time options. The rationale for this is that configurations should be portable across systems and having compile-time options prevent that.<br />
<br />
Hopefully this will provide a source of information about exactly what certain kinds of dotfiles are and where they come from.<br />
<br />
__TOC__<br />
<br />
==The XDG Base Directory Specification==<br />
<br />
Please read the [http://standards.freedesktop.org/basedir-spec/latest/ full specification]. This section will attempt to break down the essence of what it tries to achieve.<br />
<br />
None of the {{ic|XDG_}} environments should be set by default except some systems do set {{ic|XDG_RUNTIME_DIR}} such as systemd (logind).<br />
<br />
All paths defined must be absolute and valid.<br />
<br />
===User Directories===<br />
<br />
* {{ic|XDG_CONFIG_HOME}}<br />
** Defaults to {{ic|HOME/.config}}<br />
** Where user-specific configurations should be written. (Like {{ic|/etc}})<br />
<br />
* {{ic|XDG_CACHE_HOME}}<br />
** Defaults to {{ic|HOME/.cache}}<br />
** Where user-specific non-essential (cached) data should be written. (Like {{ic|/var/cache}})<br />
<br />
* {{ic|XDG_DATA_HOME}}<br />
** Defaults to {{ic|HOME/.local/share}}<br />
** Where user-specific data files should be written. (Like {{ic|/usr/share}})<br />
<br />
===System Directories===<br />
<br />
* {{ic|XDG_DATA_DIRS}}<br />
** List of directories seperated by {{ic|:}} (Like {{ic|PATH}})<br />
** Defaults to {{ic|/usr/local/share:/usr/share}}<br />
<br />
* {{ic|XDG_CONFIG_DIRS}}<br />
** List of directories seperated by {{ic|:}} (Like {{ic|PATH}})<br />
** Defaults to {{ic|/etc/xdg}}<br />
<br />
* {{ic|XDG_RUNTIME_DIR}}<br />
** Used for non-essential, user-specific data files such as sockets, named pipes, etc.<br />
** Defaults to nothing, warnings should be issued if not set or equivalents provided.<br />
** Must be owned by the user with an access mode of {{ic|0700}}.<br />
** Filesystem fully featured by standards of OS.<br />
** Must be on the local filesystem.<br />
** May be subject to periodic cleanup.<br />
** Modified every 6 hours or set sticky bit if persistence is desired.<br />
** Can only exist for the duration of the user's login.<br />
** Should not store large files as it may be mounted as a tmpfs.<br />
<br />
==Exceptions==<br />
<br />
These directories and files are unlikely to ever change, there is far too much historical baggage and most tools written expect these files and directories to exist in these locations.<br />
<br />
While some of these tools are still in active development and maintainence, the developers are unwilling to accommodate for the necessary changes due to the aforementioned reasons.<br />
<br />
; {{ic|~/.ssh}}<br />
: Assumed to be present by many ssh daemons and clients such as DropBear and OpenSSH. [https://bugzilla.mindrot.org/show_bug.cgi?id=2050 OpenSSH Bug 2050]<br />
<br />
; {{ic|~/.pki}}<br />
: Part of Mozilla's [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS Project].<br />
<br />
; {{ic|~/.netrc}}<br />
: Like {{ic|~/.ssh}}, many programs expect this file to be here. These include projects like curl ({{ic|CURLOPT_NETRC_FILE}}), ftp ({{ic|NETRC}}), s-nail ({{ic|NETRC}}), etc. While some of them offer alternative configurable locations, many do not such as w3m, wget and lftp.<br />
<br />
; {{ic|~/.dbus}}<br />
: Is unfortunately required by the specification, an oversight to be sure. [https://bugs.freedesktop.org/show_bug.cgi?id=35887 Bug 35887]<br />
<br />
; {{ic|~/.profile}}<br />
: Used by the various shells and display managers, this file is expected to be here much like {{ic|~/.netrc}}.<br />
<br />
; {{ic|~/.cups}}<br />
; Used by the CUPS printing daemon. Upstream will not change the location of this directory, [http://www.cups.org/str.php?L4243]<br />
<br />
==Contributing==<br />
<br />
When contributing make sure to use the correct section.<br />
<br />
Nothing should require code evaluation (such as [[vim]] and {{ic|VIMINIT}}), patches or compile-time options to gain support and anything which does must be deemed hardcoded. Additionally if the process is too error prone or difficult, such as [https://www.haskell.org/cabal/ Haskell's cabal] or eclipse, they should also be considered as hardcoded.<br />
<br />
* The first column should be the project name, ideally the command name if it is not ambigious, linked to their website or an appropriate internal wiki article.<br />
<br />
* The second column is for any legacy files and directories the project had, this is done so people can find them even if they are no longer read.<br />
<br />
* Try to find the commit or version a project switched to XDG Base Directory or any open discussions and include them in the next two columns.<br />
<br />
* Finally include any appropriate workarounds or solutions for unsupported projects. Be terse, this article assumes intelligence and good charity from the reader. If something is unclear then feel free to expend some explanation to clarify it.<br />
<br />
Lastly, and this goes without saying, please verify that your solution is correct and functional.<br />
<br />
==Supported==<br />
<br />
{| class="wikitable sortable" style="width: 100%"<br />
! Application<br />
! Legacy Path<br />
! Supported Since<br />
! Discussion<br />
! Notes<br />
|-<br />
| [https://github.com/Ryochan7/antimicro/ antimicro]<br />
| {{ic|~/.antimicro}}<br />
| [https://github.com/Ryochan7/antimicro/commit/edba864 edba864]<br />
| [https://github.com/Ryochan7/antimicro/issues/5]<br />
|<br />
|-<br />
| [https://github.com/tatsuhiro-t/aria2/ aria2]<br />
| {{ic|~/.aria2}}<br />
| [https://github.com/tatsuhiro-t/aria2/commit/8bc1d37 8bc1d37]<br />
| [https://github.com/tatsuhiro-t/aria2/issues/27]<br />
|<br />
|-<br />
| [http://www.blender.org/ blender]<br />
| {{ic|~/.blender}}<br />
| [http://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/4293f473 4293f473]<br />
| [https://developer.blender.org/T28943]<br />
|<br />
|-<br />
| [https://github.com/falconindy/burp burp]<br />
|<br />
| [https://github.com/falconindy/burp/commit/f2388e9 f2388e9]<br />
|<br />
|<br />
|-<br />
| [[chromium]]<br />
| {{ic|~/.chromium}}<br />
| [https://src.chromium.org/viewvc/chrome?revision=23057&view=revision 23057]<br />
| [https://groups.google.com/forum/#!topic/chromium-dev/QekVQxF3nho] [https://code.google.com/p/chromium/issues/detail?id=16976]<br />
|<br />
|-<br />
| [https://github.com/falconindy/cower cower]<br />
|<br />
| [https://github.com/falconindy/cower/commit/8b70805 8b70805]<br />
|<br />
|<br />
|-<br />
| [https://wiki.gnome.org/dconf dconf]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [https://wiki.gnome.org/Apps/DFeet d-feet]<br />
| {{ic|~/.d-feet}}<br />
| [https://git.gnome.org/browse/d-feet/commit/?id==7f6104b 7f6104b]<br />
|<br />
|<br />
|-<br />
| [http://www.knopwob.org/dunst/index.html dunst]<br />
|<br />
| [https://github.com/knopwob/dunst/commit/78b6e2b1 78b6e2b1]<br />
| [https://github.com/knopwob/dunst/issues/22]<br />
|<br />
|-<br />
| [[dwb]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[fontconfig]]<br />
| {{ic|~/.fontconfig}}<br />
| [http://cgit.freedesktop.org/fontconfig/commit/?id=8c255fb1 8c255fb1]<br />
|<br />
|<br />
|-<br />
| [http://fontforge.github.io/ fontforge]<br />
| {{ic|~/.FontForge}} {{ic|~/.PfaEdit}}<br />
| [https://github.com/fontforge/fontforge/commit/e4c2cc7432 e4c2cc7432]<br />
| [https://github.com/fontforge/fontforge/issues/847] [https://github.com/fontforge/fontforge/issues/991]<br />
|<br />
|-<br />
| [[fontconfig]]<br />
| {{ic|~/.fonts}}<br />
|<br />
|<br />
| Use {{ic|"$XDG_DATA_HOME"/fonts}} instead.<br />
|-<br />
| [https://projects.gnome.org/gconf gconf]<br />
| {{ic|~/.gconf}}<br />
| [https://git.gnome.org/browse/gconf/commit/?id=fc28caa7 fc28caa7]<br />
| [https://bugzilla.gnome.org/show_bug.cgi?id=674803]<br />
|<br />
|-<br />
| [[git]]<br />
| {{ic|~/.gitconfig}}<br />
| [https://github.com/git/git/commit/0d94427e 0d94427e]<br />
|<br />
|<br />
|-<br />
| [http://gstreamer.freedesktop.org/ gstreamer-1.0]<br />
|<br />
| [http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=4e36f93924cf 4e36f93924cf]<br />
| [https://bugzilla.gnome.org/show_bug.cgi?id=518597]<br />
|<br />
|-<br />
| [[gtk|gtk3]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [http://hisham.hm/htop/ htop]<br />
| {{ic|~/.htoprc}}<br />
| [https://github.com/hishamhm/htop/commit/93233a67 93233a67]<br />
|<br />
|<br />
|-<br />
| [[i3]]<br />
| {{ic|~/.i3}}<br />
| [http://code.stapelberg.de/git/i3/commit/?id=7c130fb54 7c130fb54]<br />
|<br />
|<br />
|-<br />
| [http://i3wm.org/i3status/ i3status]<br />
| {{ic|~/.i3status.conf}}<br />
| [http://code.stapelberg.de/git/i3status/commit/?id=c3f7fc4994 c3f7fc4994]<br />
|<br />
|<br />
|-<br />
| [http://www.imagemagick.org/script/index.php imagemagick]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[inkscape]]<br />
| {{ic|~/.inkscape}}<br />
| [http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Preferences 0.47]<br />
| [https://bugs.launchpad.net/inkscape/+bug/199720]<br />
|<br />
|-<br />
| [https://github.com/Sude-/lgogdownloader/ lgogdownloader]<br />
| {{ic|~/.gogdownloader}}<br />
| [https://github.com/Sude-/lgogdownloader/commit/d430af63d000 d430af63d000]<br />
| [https://github.com/Sude-/lgogdownloader/issues/4]<br />
|<br />
|-<br />
| [[livestreamer]]<br />
| {{ic|~/.livestreamerrc}}<br />
| [https://github.com/chrippa/livestreamer/commit/ea805917 ea805917]<br />
| [https://github.com/chrippa/livestreamer/pull/106]<br />
|<br />
|-<br />
| [[llpp]]<br />
|<br />
| [http://repo.or.cz/w/llpp.git/commit/3ab86f0cb 3ab86f0cb]<br />
|<br />
| Currently llpp places the configuration directly under {{ic|XDG_CONFIG_HOME}} instead of creating a directory.<br />
|-<br />
| [[mc]]<br />
| {{ic|~/.mc}}<br />
| [https://www.midnight-commander.org/changeset/1b9957058 1b9957058] [https://www.midnight-commander.org/changeset/0b7115647 0b7115647] [https://www.midnight-commander.org/changeset/ce401d797 ce401d797]<br />
| [https://www.midnight-commander.org/ticket/1851]<br />
|<br />
|-<br />
| [[mpd]]<br />
| {{ic|~/.mpdconf}}<br />
| [http://git.musicpd.org/cgit/master/mpd.git/commit/?id=87b73284 87b73284]<br />
|<br />
|<br />
|-<br />
| [[mpv]]<br />
| {{ic|~/.mpv}}<br />
| [https://github.com/mpv-player/mpv/commit/cb250d490 cb250d490]<br />
| [https://github.com/mpv-player/mpv/pull/864]<br />
|<br />
|-<br />
| [http://mypaint.intilinux.com/ mypaint]<br />
| {{ic|~/.mypaint}}<br />
| [https://github.com/mypaint/mypaint/commit/cf723b74cd cf723b74cd]<br />
|<br />
|<br />
|-<br />
| [[newsbeuter]]<br />
| {{ic|~/.newsbeuter}}<br />
| [https://github.com/akrennmair/newsbeuter/commit/3c57824c5 3c57824c5]<br />
| [https://github.com/akrennmair/newsbeuter/pull/39]<br />
| It is required to create both {{ic|"$XDG_DATA_HOME"/newsbeuter}} and {{ic|"$XDG_CONFIG_HOME"/newsbeuter}} [http://newsbeuter.org/doc/newsbeuter.html#_xdg_base_directory_support]<br />
|-<br />
| [[OfflineIMAP]]<br />
| {{ic|~/.offlineimaprc}}<br />
| [https://github.com/OfflineIMAP/offlineimap/commit/5150de5 5150de5]<br />
| [https://github.com/OfflineIMAP/offlineimap/issues/32]<br />
|<br />
|-<br />
| [http://pcsx2.net/ pcsx2]<br />
| {{ic|~/.pcsx2}}<br />
| [https://github.com/PCSX2/pcsx2/commit/87f1e8f77 87f1e8f77] [https://github.com/PCSX2/pcsx2/commit/a9020c606 a9020c606] [https://github.com/PCSX2/pcsx2/commit/3b22f0fb0 3b22f0fb0] [https://github.com/PCSX2/pcsx2/commit/0a012aec2 0a012aec2]<br />
| [https://github.com/PCSX2/pcsx2/issues/352] [https://github.com/PCSX2/pcsx2/issues/381]<br />
|<br />
|-<br />
| [http://www.ppsspp.org/ ppsspp]<br />
| {{ic|~/.ppsspp}}<br />
| [https://github.com/hrydgard/ppsspp/commit/132fe47c7d 132fe47c7d]<br />
| [https://github.com/hrydgard/ppsspp/issues/4623]<br />
|<br />
|-<br />
| [https://github.com/Cloudef/orbment/ orbment]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[pacman]]<br />
| {{ic|~/.makepkg.conf}}<br />
| [https://projects.archlinux.org/pacman.git/commit/?id=80eca94c8 80eca94c8]<br />
| [https://mailman.archlinux.org/pipermail/pacman-dev/2014-July/019178.html]<br />
|<br />
|-<br />
| [[PulseAudio]]<br />
| {{ic|~/.pulse}} {{ic|~/.pulse-cookie}}<br />
| [http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=59a8618dcd9 59a8618dcd9] [http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=87ae8307057 87ae8307057] [http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=9ab510a6921 9ab510a6921] [http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=4c195bcc9d5 4c195bcc9d5]<br />
| [https://bugzilla.redhat.com/show_bug.cgi?id=845607]<br />
|<br />
|-<br />
| [[qutebrowser]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[systemd]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[termite]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[transmission]]<br />
| {{ic|~/.transmission}}<br />
| [https://trac.transmissionbt.com/changeset/5517 5517]<br />
| [https://trac.transmissionbt.com/ticket/684]<br />
|<br />
|-<br />
| [https://www.kernel.org/pub/linux/utils/util-linux/ util-linux]<br />
|<br />
| [http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=570b32100 570b32100]<br />
|<br />
|<br />
|-<br />
|[http://www.freerdp.com/ freerdp]<br />
|{{ic|~/.freerdp}}<br />
|[https://github.com/FreeRDP/FreeRDP/commit/edf6e7258d edf6e7258d]<br />
|<br />
|<br />
|-<br />
| [http://beets.radbox.org/ beets]<br />
|<br />
|<br />
|<br />
|-<br />
| [http://pyroom.org/index.html pyroom]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [http://citra-emu.org/ citra]<br />
| {{ic|~/.citra-emu}}<br />
| [https://github.com/citra-emu/citra/commit/f7c3193fec f7c3193fec]<br />
| [https://github.com/citra-emu/citra/pull/575]<br />
|<br />
|-<br />
| [http://www.libretro.com/ retroarch]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [http://lftp.yar.ru/ lftp]<br />
| {{ic|~/.lftp}}<br />
| [https://github.com/lavv17/lftp/commit/21dc400 21dc400]<br />
| [https://www.mail-archive.com/lftp@uniyar.ac.ru/msg04301.html]<br />
|<br />
|-<br />
| [https://github.com/derat/xsettingsd xsettingsd]<br />
| {{ic|~/.xsettingsd}}<br />
| [https://github.com/derat/xsettingsd/commit/b4999f5e9e99224caf97d09f25ee731774ecd7be 4ecd7be]<br />
|<br />
|<br />
|-<br />
| [[surfraw]]<br />
| {{ic|~/.surfraw.conf}} {{ic|~/.surfraw.bookmarks}}<br />
| [http://anonscm.debian.org/cgit/surfraw/surfraw.git/commit/?id=3e4591d8 3e4591d8] [http://anonscm.debian.org/cgit/surfraw/surfraw.git/commit/?id=bd8c427d bd8c427d] [http://anonscm.debian.org/cgit/surfraw/surfraw.git/commit/?id=f57fc718 f57fc718]<br />
|<br />
|<br />
|-<br />
| [http://milkytracker.org/ milkytracker]<br />
| {{ic|~/.milkytracker_config}}<br />
| [https://github.com/Deltafire/MilkyTracker/commit/eb487c55 eb487c55]<br />
| [https://github.com/Deltafire/MilkyTracker/issues/12]<br />
|<br />
|-<br />
| [https://github.com/SirCmpwn/sway sway]<br />
| {{ic|~/.sway/config}}<br />
| [https://github.com/SirCmpwn/sway/commit/614393c09 614393c09]<br />
| [https://github.com/SirCmpwn/sway/issues/5] <br />
|<br />
|-<br />
| [[fish]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [https://bitbucket.org/opentyrian/opentyrian/wiki/Home opentyrian]<br />
| {{ic|~/.opentyrian}}<br />
| [https://bitbucket.org/opentyrian/opentyrian/commits/8d45ff2 8d45ff2]<br />
| [https://web.archive.org/web/20140815181350/http://code.google.com/p/opentyrian/issues/detail?id=125]<br />
|<br />
|}<br />
<br />
==Partial==<br />
{| class="wikitable sortable" style="width: 100%"<br />
! Application<br />
! Legacy Path<br />
! Supported Since<br />
! Discussion<br />
! Notes<br />
|-<br />
| [http://abook.sourceforge.net/ abook]<br />
| {{ic|~/.abook}}<br />
|<br />
|<br />
| {{ic|$ abook --config "$XDG_CONFIG_HOME"/abook/abookrc \<br />
--datafile "$XDG_CACHE_HOME"/abook/addressbook}}<br />
|-<br />
| [http://aspell.net/ aspell]<br />
| {{ic|~/.aspell.conf}}<br />
|<br />
|<br />
|<br />
|-<br />
| [http://crates.io/ cargo]<br />
| {{ic|~/.cargo}}<br />
|<br />
| [https://github.com/rust-lang/cargo/pull/148] [https://github.com/rust-lang/cargo/issues/1734]<br />
| {{ic|1=$ export CARGO_HOME="$XDG_DATA_HOME"/cargo}}<br />
|-<br />
| [[ccache]]<br />
| {{ic|~/.ccache}}<br />
| <br />
| <br />
| {{ic|1=$ export CCACHE_DIR="$XDG_CACHE_HOME"/ccache}}<br />
|-<br />
| [[conky]]<br />
| {{ic|~/.conkyrc}}<br />
|<br />
|<br />
| {{ic|1=$ conky --config="$XDG_CONFIG_HOME"/conky/conkyrc}}<br />
|-<br />
| [http://www.dungeoncrawl.org/ crawl]<br />
| {{ic|~/.crawl}}<br />
|<br />
|<br />
| {{ic|1=$ export CRAWL_DIR="$XDG_DATA_HOME"/crawl/ # Trailing '/' is required.}}<br />
|-<br />
| [https://www.gnu.org/software/coreutils/ coreutils]<br />
| {{ic|~/.dircolors}}<br />
|<br />
|<br />
| {{ic|$ source "$(dircolors "$XDG_CONFIG_HOME"/dircolors)"}}<br />
|-<br />
| [[ELinks]]<br />
| {{ic|~/.elinks}}<br />
|<br />
|<br />
| {{ic|1=$ export ELINKS_CONFDIR="$XDG_CONFIG_HOME"/elinks}}<br />
|-<br />
| [[PulseAudio]]<br />
| {{ic|~/.esd_auth}}<br />
|<br />
|<br />
| Very likely generated by the {{ic|module-esound-protocol-unix.so}} module. It can be configured to use a different location but it makes much more sense to just comment out this module in {{ic|/etc/pulse/default.pa}} or {{ic|$XDG_CONFIG_HOME/pulse/default.pa}}.<br />
|-<br />
| [http://www.gnu.org/software/gdb/ gdb]<br />
| {{ic|~/.gdbinit}}<br />
|<br />
|<br />
| {{ic|$ gdb -nh -x "$XDG_CONFIG_HOME"/gdb/init}}<br />
|-<br />
| [[gimp]]<br />
| {{ic|~/.gimp-2.8}}<br />
| [https://git.gnome.org/browse/gimp/commit/?id=60e0cfe 60e0cfe]<br />
| [https://bugzilla.gnome.org/show_bug.cgi?id=166643] [https://mail.gnome.org/archives/gimp-developer-list/2012-October/msg00028.html]<br />
| {{ic|1=$ export GIMP2_DIRECTORY="$XDG_CONFIG_HOME"/gimp}}<br />
|-<br />
| [http://guichaz.free.fr/gliv/ gliv]<br />
| {{ic|~/.glivrc}}<br />
|<br />
|<br />
| {{ic|1=$ gliv --glivrc="$XDG_CONFIG_HOME"/gliv/glivrc}}<br />
|-<br />
| [[GPG|gpg]]<br />
| {{ic|~/.gnupg}}<br />
|<br />
|<br />
| {{ic|1=$ export GNUPGHOME="$XDG_CONFIG_HOME/gnupg}}<br />
{{ic|$ gpg2 --homedir "$XDG_CONFIG_HOME/gnupg}}<br />
|-<br />
| [[gtk|gtk2]]<br />
| {{ic|~/.gtkrc-2.0}}<br />
|<br />
|<br />
| {{ic|1=$ export GTK2_RC_FILES="$XDG_CONFIG_HOME"/gtk-2.0/gtkrc}}<br />
|-<br />
| [[gtk]]<br />
| {{ic|~/.gtkrc}}<br />
|<br />
|<br />
| {{ic|1=$ export GTK_RC_FILES="$XDG_CONFIG_HOME"/gtk-1.0/gtkrc}}<br />
|-<br />
| [http://httpie.org httpie]<br />
| {{ic|~/.httpie}}<br />
|<br />
| [https://github.com/jakubroztocil/httpie/issues/145]<br />
| {{ic|1=$ export HTTPIE_CONFIG_DIR="$XDG_CONFIG_HOME"/httpie}}<br />
|-<br />
| [http://ipython.org ipython]/[http://jupyter.org jupyter]<br />
| {{ic|~/.ipython}}<br />
|<br />
|<br />
| {{ic|1=$ export IPYTHONDIR="$XDG_CONFIG_HOME"/jupyter}}{{ic|1=$ export JUPYTER_CONFIG_DIR="$XDG_CONFIG_HOME"/jupyter}}<br />
|-<br />
| [http://isync.sourceforge.net isync]<br />
| {{ic|~/.mbsyncrc}}<br />
|<br />
|<br />
| {{ic|$ mbsync -c "$XDG_CONFIG_HOME"/isync/mbsyncrc}}<br />
|-<br />
| [ftp://www.x.org/pub/xorg/current/doc/libICE/ice.html libice]<br />
| {{ic|~/.ICEauthority}}<br />
| <br />
| <br />
| {{ic|1=$ export ICEAUTHORITY="$XDG_RUNTIME_DIR"/X11/iceauthority}}<br />
|-<br />
| [http://www.greenwoodsoftware.com/less/ less]<br />
| {{ic|~/.lesshst}}<br />
|<br />
|<br />
| {{ic|1=$ export LESSHISTFILE="$XDG_CACHE_HOME"/less/history}}<br />
{{ic|1=$ export LESSHISTFILE=-}} can be used to disable this feature.<br />
|-<br />
| [http://www.wolfram.com/mathematica/ Mathematica]<br />
| {{ic|~/.Mathematica}}<br />
|<br />
|<br />
| {{ic|1=$ export MATHEMATICA_USERBASE="$XDG_CONFIG_HOME"/mathematica}}<br />
|-<br />
| [http://mednafen.sourceforge.net/ mednafen]<br />
| {{ic|~/.mednafen}}<br />
|<br />
|<br />
| {{ic|1=$ export MEDNAFEN_HOME="$XDG_CONFIG_HOME"/mednafen}}<br />
|-<br />
| [[moc]]<br />
| {{ic|~/.moc}}<br />
|<br />
|<br />
| {{ic|$ mocp -M "$XDG_CONFIG_HOME"/moc}}<br />
{{ic|1=$ mocp -O MOCDir="$XDG_CONFIG_HOME"/moc}}<br />
|-<br />
| [[MPlayer]]<br />
| {{ic|~/.mplayer}}<br />
|<br />
|<br />
| {{ic|1=$ export MPLAYER_HOME="$XDG_CONFIG_HOME"/mplayer}} <br />
|-<br />
| [[mutt]]<br />
| {{ic|~/.mutt}}<br />
|<br />
| [http://dev.mutt.org/trac/ticket/3207]<br />
| {{ic|$ mutt -F "$XDG_CONFIG_HOME"/mutt/muttrc}}<br />
{{hc|muttrc|<br />
set header_cache &#61; ~/.cache/mutt/headers<br />
set message_cachedir &#61; ~/.cache/mutt/messages<br />
set mailcap_path &#61; ~/.config/mutt/mailcap<br />
set record &#61; ~/.config/mutt/record/sent<br />
}}<br />
|-<br />
| [[ncmpcpp]]<br />
| {{ic|~/.ncmpcpp}}<br />
|<br />
|<br />
| {{ic|$ ncmpcpp -c "$XDG_CONFIG_HOME"/ncmpcpp/config}}<br />
|-<br />
| [[notmuch]]<br />
| {{ic|~/.notmuch-config}}<br />
|<br />
| [http://notmuchmail.org/pipermail/notmuch/2011/007007.html]<br />
| {{ic|1=$ export NOTMUCH_CONFIG="$XDG_CONFIG_HOME"/notmuch/notmuchrc}}<br />
{{ic|1=$ export NMBGIT="$XDG_DATA_HOME"/notmuch/nmbug}}<br />
|-<br />
| {{pkg|ncurses}}<br />
| {{ic|~/.terminfo}}<br />
|<br />
|<br />
| {{ic|1=$ export TERMINFO="$XDG_DATA_HOME"/terminfo # Precludes system path searching.}}<br />
{{ic|1=$ export TERMINFO_DIRS="$XDG_DATA_HOME"/terminfo:/usr/share/terminfo}}<br />
|-<br />
| [[NVIDIA]], [[CUDA]]<br />
| {{ic|~/.nv}}<br />
|<br />
|<br />
| {{ic|1=$ export __GL_SHADER_DISK_CACHE_PATH="$XDG_CACHE_HOME"/nv}}<br />
{{ic|1=$ export CUDA_CACHE_PATH="$XDG_CACHE_HOME"/nv}}<br />
|-<br />
| [http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html readline]<br />
| {{ic|~/.inputrc}}<br />
|<br />
|<br />
| {{ic|1=$ export INPUTRC="$XDG_CONFIG_HOME"/readline/inputrc}}<br />
|-<br />
| [http://rr-project.org/ rr]<br />
| {{ic|~/.rr}}<br />
|<br />
| [https://github.com/mozilla/rr/issues/1455]<br />
| {{ic|1=$ export _RR_TRACE_DIR=$XDG_DATA_HOME/rr}}<br />
|-<br />
| [[screen]]<br />
| {{ic|~/.screenrc}}<br />
| <br />
| <br />
| {{ic|1=$ export SCREENRC="$XDG_CONFIG_HOME"/screen/screenrc}}<br />
|-<br />
| [[tmux]]<br />
| {{ic|~/.tmux.conf}}<br />
|<br />
| [http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/6013] [http://sourceforge.net/p/tmux/mailman/message/30619546/]<br />
| {{ic|$ tmux -f "$XDG_CONFIG_HOME"/tmux/tmux.conf}}<br />
{{ic|1= $ export TMUX_TMPDIR="$XDG_RUNTIME_DIR"/tmux}}<br />
|-<br />
| [[Rxvt-unicode#Daemon-client|urxvtd]]<br />
| {{ic|~/.urxvt/urxvtd-hostname}}<br />
|<br />
|<br />
| {{ic|1=$ export RXVT_SOCKET="$XDG_RUNTIME_DIR"/urxvt/urxvt-"$(hostname)"}}<br />
|-<br />
| [[WeeChat]]<br />
| {{ic|~/.weechat}}<br />
|<br />
| [http://savannah.nongnu.org/task/?10934]<br />
| {{ic|1=$ export WEECHAT_HOME="$XDG_CONFIG_HOME"/weechat}}<br />
{{ic|$ weechat -d "$XDG_CONFIG_HOME"/weechat}}<br />
|-<br />
| [[wine]]<br />
| {{ic|~/.wine}}<br />
|<br />
| [https://bugs.winehq.org/show_bug.cgi?id=20888]<br />
| {{ic|1=$ export WINEPREFIX="$XDG_DATA_HOME"/wine}}<br />
|-<br />
| [[wireshark]]<br />
| {{ic|~/.wireshark}}<br />
|<br />
| [https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6353]<br />
| {{ic|1=$ export WIRESHARK_DATA_DIR="$XDG_CONFIG_HOME"/wireshark}}<br />
|-<br />
| {{pkg|xorg-xauth}}<br />
| {{ic|~/.Xauthority}}<br />
|<br />
|<br />
| {{ic|1=$ export XAUTHORITY="$XDG_RUNTIME_DIR"/X11/xauthority}}<br />
|-<br />
| [http://www.x.org/wiki/ libx11]<br />
| {{ic|~/.XCompose}}<br />
|<br />
|<br />
| {{ic|1=$ export XCOMPOSEFILE="$XDG_CONFIG_HOME"/X11/xcompose}}<br />
|-<br />
| {{pkg|xorg-xinit}}<br />
| {{ic|~/.xinitrc}}<br />
|<br />
|<br />
| {{ic|1=$ export XINITRC="$XDG_CONFIG_HOME"/X11/xinitrc}} <br />
|-<br />
| {{pkg|xorg-xrdb}}<br />
| {{ic|~/.Xresources}} {{ic|~/.Xdefaults}}<br />
|<br />
|<br />
| Ultimately you [http://superuser.com/questions/243914/xresources-or-xdefaults should be] using {{ic|Xresources}} and since these resources are loaded via {{ic|xrdb}} you can specify a path such as {{ic|xrdb -load ~/.config/X11/xresources}}.<br />
|-<br />
| [http://www.openscad.org/ openscad]<br />
| {{ic|~/.OpenSCAD}}<br />
| [https://github.com/openscad/openscad/commit/7c3077b0f 7c3077b0f]<br />
| [https://github.com/openscad/openscad/issues/125]<br />
| Does not fully honour XDG Base Directory Specification, see [https://github.com/openscad/openscad/issues/373]<br />
<br />
Currently it [https://github.com/openscad/openscad/blob/master/src/PlatformUtils-posix.cc#L20 hard-codes] {{ic|~/.local/share}}.<br />
|-<br />
|[http://www.videolan.org/developers/libdvdcss.html libdvdcss]<br />
|{{ic|~/.dvdcss}}<br />
|<br />
|[https://mailman.videolan.org/pipermail/libdvdcss-devel/2014-August/001022.html]<br />
|{{ic|1=$ export DVDCSS_CACHE="$XDG_DATA_HOME"/dvdcss}}<br />
|-<br />
| [http://jonas.nitro.dk/tig/ tig]<br />
| {{ic|~/.tigrc}}<br />
| <br />
| <br />
| {{ic|1=$ export TIGRC_USER="$XDG_CONFIG_HOME"/tig/tigrc}}<br />
|-<br />
| [http://utopia.knoware.nl/~hlub/uck/rlwrap/ rlwrap]<br />
| {{ic|~/.*_history}}<br />
|<br />
| [https://github.com/hanslub42/rlwrap/issues/25]<br />
| {{ic|1=$ export RLWRAP_HOME="$XDG_DATA_HOME"/rlwrap}}<br />
|-<br />
| [https://github.com/bengardner/uncrustify uncrustify]<br />
| {{ic|~/.uncrustify.cfg}}<br />
|<br />
|<br />
| {{ic|1=$ export UNCRUSTIFY_CONFIG="$XDG_CONFIG_HOME"/uncrustify/uncrustify.cfg}}<br />
|-<br />
| [http://www.vergenet.net/~conrad/software/xsel/ xsel]<br />
| {{ic|~/.xsel.log}}<br />
| <br />
| [https://github.com/kfish/xsel/issues/10]<br />
| {{ic|1=$ xsel --logfile "$XDG_CACHE_HOME"/xsel/xsel.log}}<br />
|-<br />
| [http://kripken.github.io/emscripten-site/ emscripten]<br />
| {{ic|~/.emscripten}} {{ic|~/.emscripten_sanity}} {{ic|~/.emscripten_ports}} {{ic|~/.emscripten_cache__last_clear}}<br />
| <br />
| [https://github.com/kripken/emscripten/issues/3624 3624]<br />
| {{ic|1=$ export EM_CONFIG="$XDG_CONFIG_HOME"/emscripten/config}}<br />
{{ic|1=$ export EM_CACHE="$XDG_CACHE_HOME"/emscripten/cache}}<br />
{{ic|1=$ export EM_PORTS="$XDG_DATA_HOME"/emscripten/cache}}<br />
{{ic|$ emcc --em-config "$XDG_CONFIG_HOME"/emscripten/config --em-cache "$XDG_CACHE_HOME"/emscripten/cache}}<br />
|-<br />
| [https://www.stackage.org/ stack]<br />
| {{ic|~/.stack}}<br />
|<br />
| [https://github.com/commercialhaskell/stack/issues/342]<br />
| {{ic|1=$ export STACK_ROOT="$XDG_DATA_HOME"/stack}}<br />
|-<br />
| [[subversion]]<br />
| {{ic|~/.subversion}}<br />
| [https://mail-archives.apache.org/mod_mbox/subversion-users/201204.mbox/%3c4F8FBCC6.4080205@ritsuka.org%3e][http://mail-archives.apache.org/mod_mbox/subversion-dev/201509.mbox/%3c20150917222954.GA20331@teapot%3e]<br />
|<br />
| {{ic|$ svn --config-dir "$XDG_CONFIG_HOME"/subversion}}<br />
|-<br />
|}<br />
<br />
==Hardcoded==<br />
<br />
{| class="wikitable sortable" style="width: 100%"<br />
! Application<br />
! Legacy Path<br />
! Supported Since<br />
! Discussion<br />
! Notes<br />
|-<br />
| [https://directory.apache.org/studio/ Apache Directory Studio]<br />
| {{ic|~/.ApacheDirectoryStudio}}<br />
|<br />
|<br />
|<br />
|-<br />
| [[AMule]]<br />
| {{ic|~/.aMule}}<br />
|<br />
|<br />
|<br />
|-<br />
| [https://www.haskell.org/cabal/ cabal]<br />
| {{ic|~/.cabal}}<br />
|<br />
| [https://github.com/haskell/cabal/issues/680]<br />
| See discussion for potential workarounds. It is not very easy or straightforward but may be possible to emulate Base Directory compliance.<br />
|-<br />
| [http://julialang.org/ julia]<br />
| {{ic|~/.juliarc.jl}} {{ic|~/.julia_history}}<br />
|<br />
| [https://github.com/JuliaLang/julia/issues/4630] [https://github.com/JuliaLang/julia/issues/10016]<br />
|<br />
|-<br />
| [http://www.milkytracker.org/ milkytracker]<br />
| {{ic|~/.milkytracker_config}}<br />
|<br />
| [https://github.com/Deltafire/MilkyTracker/issues/12]<br />
|<br />
|-<br />
| [http://neovim.io/ neovim]<br />
| {{ic|~/.nvim}} {{ic|~/.nvimlog}} {{ic|~/.nviminfo}}<br />
|<br />
| [https://github.com/neovim/neovim/issues/78] [https://github.com/neovim/neovim/pull/3198]<br />
|<br />
|-<br />
| [[firefox]]<br />
| {{ic|~/.mozilla}}<br />
|<br />
| [https://bugzil.la/259356]<br />
|<br />
|-<br />
| [http://gstreamer.freedesktop.org/documentation/gstreamer010.html gstreamer-0.10]<br />
| {{ic|~/.gstreamer-0.10}}<br />
| <br />
| <br />
| Use [http://gstreamer.freedesktop.org/ gstreamer-1.0] instead.<br />
|-<br />
| [[python]]<br />
| {{ic|~/.python_history}}<br />
|<br />
|<br />
| All history from interactive sessions is saved to {{ic|~/.python_history}} by default since [https://bugs.python.org/issue5845 version 3.4], custom path can still be set the same way as in older versions (see [https://docs.python.org/3/library/readline.html?highlight=readline#example this example]).<br />
|-<br />
| {{pkg|procps-ng}}<br />
| {{ic|~/.toprc}}<br />
|<br />
| [https://bugzilla.redhat.com/show_bug.cgi?id=1155265]<br />
|<br />
|-<br />
| [[vim]]<br />
| {{ic|~/.vim}} {{ic|~/.vimrc}} {{ic|~/.viminfo}}<br />
|<br />
|<br />
| Since [https://github.com/vim/vim/commit/6a459902592e2a4ba68 7.3.1178] vim will search for {{ic|~/.vim/vimrc}} if {{ic|~/.vimrc}} is not found.<br />
<br />
{{hc|~/.vim/vimrc|<br />
set undodir&#61;~/.cache/vim/undo " vim will not create this directory.<br />
set directory&#61;~/.cache/vim/swap " vim will not create this directory.<br />
set backupdir&#61;~/.cache/vim/backup " vim will not create this directory.<br />
set viminfo+&#61;n~/.cache/vim/viminfo<br />
}}<br />
<br />
* https://tlvince.com/vim-respect-xdg<br />
|-<br />
| {{pkg|xdg-utils}}<br />
| {{ic|~/.gnome}}<br />
|<br />
|<br />
| For some reason the script {{ic|xdg-desktop-menu}} hard-codes {{ic|gnome_user_dir&#61;"$HOME/.gnome/apps"}}. This is used by [[chromium]] amoung others.<br />
|-<br />
| [[sqlite]]<br />
| {{ic|~/.sqlite_history}}<br />
|<br />
|<br />
|<br />
|-<br />
| [http://w1.fi/ wpa_cli]<br />
| {{ic|~/.wpa_cli_history}}<br />
|<br />
|<br />
|<br />
|-<br />
| [[xmonad]]<br />
| {{ic|~/.xmonad}}<br />
|<br />
| [https://code.google.com/p/xmonad/issues/detail?id=484]<br />
|<br />
|-<br />
| [[eclipse]]<br />
| {{ic|~/.eclipse}}<br />
| <br />
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=200809]<br />
| Option {{ic|1=-Dosgi.configuration.area=@user.home/.config/..}} overrides but must be added to {{ic|"$ECLIPSE_HOME"/eclipse.ini"}} rather than command line which means you must have write access to {{ic|$ECLIPSE_HOME}}. (Arch Linux hard-codes {{ic|$ECLIPSE_HOME}} in {{ic|/usr/bin/eclipse}})<br />
|-<br />
|[https://perf.wiki.kernel.org/index.php/Main_Page perf]<br />
|{{ic|~/.debug}}<br />
|<br />
|<br />
|Hardcoded in [https://github.com/torvalds/linux/blob/master/tools/perf/util/config.c#L18 tools/perf/util/config.c:18].<br />
|-<br />
| [[zsh]]<br />
| {{ic|~/.zshrc}} {{ic|~/.zprofile}} {{ic|~/.zshenv}} {{ic|~/.zlogin}} {{ic|~/.zlogout}} {{ic|~/.zsh_history}} {{ic|~/.zhistory}}<br />
| <br />
| [http://www.zsh.org/mla/workers/2013/msg00692.html]<br />
| Consider exporting {{ic|1=ZDOTDIR="$XDG_CONFIG_HOME"/zsh}} in {{ic|~/.zshenv}}. You could also add this to {{ic|/etc/zsh/zshenv}} and avoid the need for any dotfiles in your {{ic|HOME}}. Doing this however requires root privilege which may not be viable and is system-wide.<br />
{{ic|1=export HISTFILE="$XDG_DATA_HOME"/zsh/history}}<br />
|-<br />
| [[bash]]<br />
| {{ic|~/.bashrc}} {{ic|~/.bash_history}} {{ic|~/.bash_profile}} {{ic|~/.bash_login}} {{ic|~/.bash_logout}}<br />
|<br />
| [http://savannah.gnu.org/support/?108134]<br />
| {{ic|1=export HISTFILE="$XDG_DATA_HOME"/bash/history}}<br />
|-<br />
| [[Dolphin emulator|dolphin-emu]]<br />
| {{ic|~/.dolphin-emu}}<br />
| <br />
| [https://github.com/dolphin-emu/dolphin/pull/2304]<br />
| <br />
|-<br />
| [http://lldb.llvm.org/ lldb]<br />
| {{ic|~/.lldb}} {{ic|~/.lldbinit}}<br />
| <br />
| <br />
|<br />
|<br />
|-<br />
| [https://www.gnu.org/software/emacs/ emacs]<br />
| {{ic|~/.emacs}} {{ic|~/.emacs.d}}<br />
|<br />
| [http://debbugs.gnu.org/cgi/bugreport.cgi?bug=583]<br />
| It's possible to set {{ic|HOME}}, but it has unexpected side effects. So far the most promising approach is modifying another Emacs environment variable to alter the load path and author your own site file which can manually load up your init file, but it changes the load process significantly.<br />
|-<br />
| [http://www.mathomatic.org/ mathomatic]<br />
| {{ic|~/.mathomaticrc}} {{ic|~/.matho_history}}<br />
|<br />
|<br />
| History can be moved by using {{ic|rlwrap mathomatic -r}} with the {{ic|RLWRAP_HOME}} environment set appropriately.<br />
|-<br />
| [https://www.mongodb.org/ mongodb]<br />
| {{ic|~/.mongorc.js}} {{ic|~/.dbshell}}<br />
|<br />
| [https://jira.mongodb.org/browse/DOCS-5652?jql=text%20~%20%22.mongorc.js%22]<br />
| [http://stackoverflow.com/a/22349050/4200039 This Stack Overflow] thread suggests a partial workaround using command-line switch {{ic|--norc}}.<br />
|}<br />
<br />
==Library and Language Support==<br />
<br />
; C<br />
: [https://github.com/Cloudef/chck/tree/master/chck/xdg C99: Cloudef's simple implementation].<br />
<br />
; Haskell<br />
: Officially in [https://hackage.haskell.org/package/directory directory] since 1.2.3.0 [https://github.com/haskell/directory/commit/ab9d0810ce ab9d0810ce].<br />
: [https://hackage.haskell.org/package/xdg-basedir xdg-basedir]<br />
<br />
; Perl<br />
: [http://search.cpan.org/dist/File-BaseDir/lib/File/BaseDir.pm File-BaseDir]<br />
: [https://github.com/Aerdan/perl-file-xdg perl-file-xdg]<br />
<br />
; Python<br />
: [http://freedesktop.org/wiki/Software/pyxdg/ pyxdg]<br />
<br />
; Vala<br />
: Builtin support via [http://valadoc.org/#!api=glib-2.0/GLib.Environment GLib.Environment].<br />
: See {{ic|get_user_cache_dir}}, {{ic|get_user_data_dir}}, {{ic|get_user_config_dir}}, etc.<br />
<br />
==See also==<br />
<br />
* [https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp Rob Pike: "Dotfiles" being hidden is a UNIXv2 mistake].<br />
* [http://www.freedesktop.org/software/systemd/man/systemd-path.html systemd-path(1)]<br />
* [http://www.freedesktop.org/software/systemd/man/file-hierarchy.html file-hierarchy(7)]<br />
* [https://github.com/grawity/dotfiles/blob/master/.dotfiles.notes Grawity's notes on dotfiles].<br />
* [https://github.com/grawity/dotfiles/blob/master/.environ.notes Grawity's notes on environment variables].<br />
* [https://ploum.net/207-modify-your-application-to-use-xdg-folders/ ploum.net: Modify Your Application to use XDG Folders].</div>Voxadam