text:
# A Begineer's Guide to Arch Linux 🐧

## Screenshots

![](./imgs/landscape_desktop.png)
![](./imgs/landscape_vscode_terminal.png)
![](./imgs/rofi_main.png)
|                                           |               |
|-------------------------------------------|----------------|
| ![](./imgs/portrait_vs_code_terminal.png) | ![](./imgs/rofi_power.png) |

## Part 1: Installing Base Arch with LVM

### **Step 1: Set the keyboard layout**
Usually if you are using an English (US) keyboard you would not need to do this. But if you need to change the keyboard, you can find the available keymmaps using the following command:
```
ls /usr/share/kbd/keymaps/**/*.map.gz
```
To change the layout, append a corresponding file name to loadkeys command, omitting path and file extension. So, for e.g. to load de-latin1 keymap execute:
```
loadkeys de-latin1
```

### **Step 2: Ensure Internet access**
Check if you have internet access by executing the following command:

`ping -c 4 archlinux.org`

If the server is unreachable there are probably some issues. If you face connectivity issue or if you want to install Arch using your WiFi please follow [ArchWiki: Connect to the internet](https://wiki.archlinux.org/index.php/installation_guide#Connect_to_the_internet)

### **Step 3: Ensure the Time and date is correct**
Before proceeding with the installation we need to make sure that the date and time on our system is correct. This is important as we'll need to download stuff from the internet for the install and wrong date/time can cause issues with the same.

Since we have the internet enabled we can enable Network Time Protocol Service to set the correct time on our machine.

`timedatectl set-ntp true`

Now make sure `ntp` has been activated by executing the following command:

`timedatectl status`

If the NTP Service is set to enabled, you're ready to move forward.

### **Step 4: Partitioning the disk**
#### **Finding the disk you want to install Arch Linux on**
Partitioning the disk is one of the most important step in the Arch installation process.

List all the disks installed on your system by running the following command:

`lsblk`

This command will print out all of the installed disks on your system. Find the name of the disk you want to install the Arch Linux. It would be something similar to **sda, sdb or sdc etc.** or if you have a NVMe drive installed it would be something along the lines of **nvme0n1 or nvme1n1** etc.

#### **Partitioning the drive**
You can use **fdisk utility** to partition the drive, run the following command with the disk you want to partition. We will pretend that we are partitioning the drive named **nvme1n1**.

For partitioning we would want to create 4 partitions:
- **Partition #1 (Bootloader):** This is where our bootloader will live. Bootloader is a program that loads the OS into the computer's memory. This is a specific place where your computer looks to find enteries for your OS. About `512MB` should be enough for this.

Note: A separate EFI partition is only needed if

- **Partition #2 (Swap):** If you run out of RAM you computer uses your non-volatile storage(SSD/HDD) as a virtual RAM. A swap partition is this allocated space on disk that is used as a virtual RAM. Size of this partition is totally up to you but I usually use 1-2 times the amount of RAM installed on the device.

- **Partition #3 (LVM):** This is where the rest of your stuff would go. The operating system, you personal files everything. We would further create virtual volumes in this  as we want to have a separate root and home partition.

We could have just create two partitions at the first place but creating volumes using LVM (virtual partitioning) makes the resizing and editing or volumes easier.

Now that we have theory out of the way, first we will create the partitions. Enter the fdisk utility using the following command:

`fdisk /dev/nvme1n1`

Now inside the **fdisk utility** press the following keys to create the partition tables on the disk:

```
press o (only if you are running BIOS mode)
press g (only if you are running UEFI mode)
```

The EFI partition is only required if you are running UEFI. If in BIOS mode you can skip ahead to the creation of the SWAP partition.
```
--- CREATING EFI PARTITION () ---
press n (to create a new partition)
press 1 (partition number)
press enter
enter +512MB (size of partition)
press t (change type of the partition)
enter 1 (change type to EFI)
```

Now its the time for **Partition #2 (Swap):**
```
--- CREATE SWAP PARTITION ---
press n (to create a new partition)
press 2 (partition number)
press enter
press +8GB (size of the swap)
press t (change type of the partition)
press 2 (change type of the partition #2)
press L (find the number corresponding to the type Linux Swap)
enter 19 (number corresponding to the type Linux Swap)
```
Finally lets create our **Partition #3 (LVM):**:
```
--- CREATE LVM PARTITION ---
press n (to create a new partition)
press 3 (partition number)
press enter
press enter (size of the LVM partition to fill rest of the disk)
press t (change type of the partition)
press 3 (change type of the partition #3)
press L (find the number corresponding to the type Linux LVM)
enter 39 (number corresponding to the type Linux LVM)
w (write to write changes)
```

#### **Setting up the LVM**
Now as mentioned previously, we would need to do the virtual partitioning of the LVM partition. First we need to initialize PhysicalVolume for later use by the Logical Volume Manager (LVM). For more details see: [pvcreate](https://linux.die.net/man/8/pvcreate)

```
pvcreate /dev/nvme1n1p3  #(If not running a SSD)
pvcreate --dataalignment 1m /dev/nvme1n1p3 #(If running a SSD)
```

```
vgcreate vg0 /dev/nvme1n1p3
# create a new volume groups to put volumes in
```
Now create logical volumes for both root and home. You can set the size of partition by using `-L 100GB` flag where 100GB would be size of partition.

Note: `-l 100%FREE` creates a volume to fill the entire free space on the volume group.
```
lvcreate -L 200GB vg0 -n lv_root
lvcreate -l 100%FREE vg0 -n lv_home
# create logical volumes

modprobe dm_mod

vgscan
# scan all disks for volume groups and rebuild caches

vgchange -ay
# activate all known volume groups in the system
```
#### Formatting the partitions
- Format EFI partition as FAT32: `mkfs.fat -F32 /dev/nvme1n1p1`
- Format the swap partition: `mkswap /dev/nvme1n1p2`
- Format the lv_root partition: `mkfs.ext4 /dev/vg0/lv_root`
- Format the lv_home partition: `mkfs.ext4 /dev/vg0/lv_home`

### Step 5: Mounting the partitions
Mount the partitions at there respective places. `swapon` here enables the partition for swapping.

```
mount /dev/vg0/lv_root /mnt
mkdir /mnt/home
mount /dev/vg0/lv_home /mnt/home
swapon /dev/nvme1n1p2
```
### Step 6: Install Arch
Congratulations! you have finally made past partitioning. Now it is time to install essential stuff. Install linux kernel and firmware executing following:

```
pacstrap /mnt base linux linux-firmware
```

### Step 7: Generate fstab
To generate the fstab, fstab file lists all available partitions and indicates how they are to be initialized or integrated into the file system structure. So basically things like what partitions exist and where they should be mounted.

```
genfstab -U /mnt >> /mnt/etc/fstab
```

### Step 8: Chroot
As of now, we are using a place on installation media as our root. Now lets change our newly root partition to be our new root.
```
arch-chroot /mnt
```

### Step 9: Change TimeZone
You can find your region by executing: `ls /usr/share/zoneinfo` and then your city using `ls /usr/share/zoneinfo/<YOUR REGION>`.

After you have found the correct region and city for you. You can simply execute the following command to set your timezone.
```
ln -sf /usr/share/zoneinfo/America/Vancouver /etc/localtime
```

### Step 10: Set System Clock
Now we need to sync the hardware and software clock. It can be done by using following command:
```
hwclock --systohc
```
For more info on this see: [hwclock](https://linux.die.net/man/8/hwclock)

### Step 11: Set Locale
Now it is time to set the locale. This is an important step and if you skip it, you might encounter some issues later on.
```
pacman -S nano vim
nano /etc/locale.gen

#----------------
# uncomment the locale by removing # sign in front of it
# for eg. change "#en_US.UTF-8 UTF-8" -> "en_US.UTF-8 UTF-8"
# and save the file
#----------------

locale-gen
```

### Step 12: Set a hostname
Now you need to set the hostname for your machine. Create a new file `/etc/hostname/` with just the hostname in it.

```
Arch-BattleStation
```

### Step 13: Create `/etc/hosts` file with following contents

```
<IP_ADDRESS>   localhost
::1         localhost
<IP_ADDRESS>   <your hostname here>.localdomain <hostname here>
```

### Step 14: Set a password for the root user
Set a password for the root user by executing `passwd`.

### Step 15: Create a new user
Now it is finally the time to create the users
```
useradd -m arshsekhon
passwd arshsekhon

# add user to the user groups for the sake of permissions
usermod -aG wheel,audio,video,storage,optical arshsekhon
```

### Step 16: Install `sudo`
Now in order to be able to execute commands as root user. We would need to install `sudo`. You probably would be familiar with `sudo` from other UNIX based systems, in Arch you would need to install it using the following command:
```
pacman -S sudo
```
Edit sudoers file by executing `visudo` and uncomment the following line and save the file:
```
%wheel ALL=(ALL) ALL
```

### Step 17:

Now we need to enable the Logical Volume Manager. This is a really really important step. Install `lvm2` using the following:
```
pacman -S lvm2
```

**Important:** Now edit `/etc/mkinitcpio.conf` and **add lvm2 in between block and filesystems**.

The file should now contain a line that looks like following:
```
HOOKS=(base udev autodetect modconf block lvm2 filesystems keyboard fsck)
```

Execute the following, to recreate initial ramdisk environment. This will ensure that the `lvm` kernel module is loaded after boot:

```
mkinitcpio -p linux
```

### Step 18: Setup bootloader
```
pacman -S grub
pacman -S efibootmgr dosfstools os-prober mtools
mkdir /boot/EFI
mount /dev/nvme1n1p1 /boot/EFI

--- IF RUNNING IN UEFI MODE ---
grub-install --target=x86_64-efi  --bootloader-id=grub_uefi --recheck
--- END ---

--- IF RUNNING IN BIOS MODE ---
grub-install --target=i386-pc /dev/nvme1n1
--- END ---

cp<EMAIL_ADDRESS>/boot/grub/locale/en.mo
grub-mkconfig -o /boot/grub/grub.cfg
```

### Step 19: Finalizing Install
Now we can finalize things by installing `NetworkManager` and `git`. Finally we will enable the `NetworkManager` service.
```
pacman -S vim networkmanager git
systemctl enable NetworkManager
```

### Step 20: Exit chroot and reboot
```
exit
umount -l /mnt
reboot
```
Now finally remove installation media.

### Step 21: Celebrate  🎉✨🎉
This is the time to give yourself a pat on the back. Now you should have a functional install of Arch Linux on your Computer.

Things might not be as pretty as you expected as you would be welcomed just by a tty, but trust me we'll get there.

## Part 2: Installing xorg, i3-wm and other GUI stuff

### Step 1: Make sure you have a working Internet Connection
Check if you have internet access by executing the following command:

`ping -c 4 archlinux.org`

If the server is unreachable there are probably some issues. If you face connectivity issue or if you want to connect to your WiFi, you would need to use `nmcli` to do so. For more info, refer to [nmcli](https://developer.gnome.org/NetworkManager/stable/nmcli.html) docs.

### Step 2: Installing Video Drivers

First and foremost we will start by installing the video drivers. If installing on a machine with NVIDIA GPU, run the following:
```
sudo pacman -S nvidia nvidia-settings nvidia-utils
sudo nvidia-xconfig
```

Otherwise, you can find the right drivers for your GPU by following steps on [Arch Wiki](https://wiki.archlinux.org/index.php/Xorg#Driver_installation).

### Step 3: Installing xorg and other packages

We will start by installing following packages:

| Package       | Purpose                                                                                |
|---------------|----------------------------------------------------------------------------------------|
| xorg          | Display Server ([more info](https://wiki.archlinux.org/index.php/Xorg))                |
| xorg-init     | Program to start xorg server ([more info](https://wiki.archlinux.org/index.php/Xinit)) |
| firefox       | Browser                                                                                |
| nitrogen      | Wallpaper Setter                                                                       |

You can do so by executing the following:

```
sudo pacman -S xorg xorg-xinit firefox picom nitrogen
```

### Step 4: Enable AUR

If you have been using linux for a while you probably would have heard of Arch User Repository (AUR). It is one of the best benifits of using Arch.

For those who are not familiar, AUR is a community-driven repository for Arch-based Linux distributions. It makes installing software insanely easy.

You can enable AUR using following:
```
sudo pacman -S base-devel
git clone https://aur.archlinux.org/yay-git.git
cd yay-git
makepkg -si
```

**WORD OF CAUTION:** Be careful about what are you installing from AUR, since this is a community based repo there can be malicious packages on AUR. So it is recommended to install only well know packages from AUR. Also, you would need AUR to compeletely follow this guide.

### Step 5: Installing more Goodies

Now we will install some more packages. Here are the packages that we will be installing

| Package                                                                    | Purpose                                                                                |
|----------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------|
| dmenu ([more info](https://wiki.archlinux.org/index.php/Dmenu))            | A lightweight menu                                                                                |
| i3-gaps-rounded-git ([more info](https://wiki.archlinux.org/index.php/I3)) | A tiling window manager ([What's a window manager?](https://wiki.archlinux.org/index.php/window_manager))  |
| nerd-fonts-mononoki                                                        | Fonts                                                                                |
| picom ([more info](https://wiki.archlinux.org/index.php/picom))            | A Compositor ([What's a compositor?](https://wiki.archlinux.org/index.php/Xorg#Composite))                 |                                                   |

You can install them by executing:

```
sudo pacman -S dmenu i3-gaps-rounded-git
yay -S nerd-fonts-mononoki picom polybar rofi alacritty
```

### Step 6: Create ~/.xinintrc
For `xorg-xinit` to work we need to have this config file. For more info, see [ArchWiki](https://wiki.archlinux.org/index.php/Xinit#xinitrc).

Copy the default file to home dir:
```
cp /etc/X11/xinit/xinitrc ~/.xinitrc
```

Open this file inside the text editor of your choice (probably vim or nano). Comment the following out from the end of the file by adding # symbol in the front of the following lines:
```
# twm &
# xclock -geometry 50x50-1+1 &
# xterm -geometry 80x50+494+51 &
# xterm -geometry  80x20+494+0 &
# exec xterm -geometry 80x66+0+0 -name login
```

### Step 7: Installing Display Manager
Right now when you boot, you are welcomed by a terminal based login screen. In order to have GUI based login screen, you would need to install a Display Manager.
For more info on Display Managers refer to the [ArchWiki](https://wiki.archlinux.org/index.php/Display_manager)

```
sudo pacman -S lightdm
yay -S lightdm-slick-greeter
```

Now modify `lightdm.config` to change the lightdm greeter by running `sudo nano /etc/lightdm/lightdm.conf`. Change the following key value pair:

```
greeter-session=lightdm-slick-greeter
```

### Step 8: Setting up audio
Let's install some packages to allow managing audio little more convenient.
```
pacman -S alsa-utils
pacman -S pulseaudio pavucontrol
```

### Step 9: Setting up Bluetooth

To use bluetooth on Arch, you would need to install `bluez` and `bluez-utils`. Then finally you can enable bluetooth service.
```
sudo pacman -S bluez bluez-utils
sudo systemctl enable bluetooth.service
```

Installing Bluetooth UI manager. After running command below you can launch the bluetooth manager by executing `blueman-manager`.

```
sudo pacman -S blueman pusleaudio-blueman
```

### Step 10: Setting up WiFi GUI

To save you the pain of having to connect to the WiFi using `nmcli` everytime, we will install a GUI tool to connect to the WiFi.
```
sudo pacman -S network-manager-applet
```

### Step 11: Reboot

Now after reboot you should be welcomed by the LightDM login screen and after loggin in you should be inside i3wm. To learn basics of how to use i3 consider watching this [Youtube Playlist](https://www.youtube.com/playlist?list=PL5ze0DjYv5DbCv9vNEzFmP6sU7ZmkGzcf).

### Step 21: Celebrate  🎉✨🎉
This is the time to give yourself a pat on the back. Now you should have a UI on your Arch Linux.

Things still might not be as pretty as you expected yet, but trust me we'll get there.

### Part 3: ✨💫💅 Ricing things up (work in progress) 💅💫✨

### Prep: Installing icons and themes

```
sudo pacman -S lxappearance materia-gtk-theme
yay -S plata-theme paper-icon-theme-git flattr-icon-theme

# clone dotfiles
git clone https://github.com/ArshSekhon/dotfiles.git ~/dotfiles

sudo pacman -S stow
```

Now you can pick and apply your favorite theme to the distro by launching `lxappearance` from the terminal.

For my install I like using `Materia - Dark` for the widgets and `Paper` for the Icons.

### Step 1: Setting up picom

```
yay -S picom-git

# copy the config files
cd ~/dotfiles
stow -Svt ~ picom

# test picom by executing
picom --experimental-backends --config ~/.config/picom.conf
```

### Step 2: Configuring polybar

```
sudo pacman -S bc jq
yay -S ttf-weather-icons zscroll-git

# copy the config files
cd ~/dotfiles
stow -Svt ~ polybar

# test polybar by executing:
~/.config/polybar/launch.sh
```

### Step 3: Configuring i3

Copy the dot files
```
# delete the default config
rm -rf ~/.config/i3
# copy the config files
cd ~/dotfiles
stow -Svt ~ i3

yay -S i3-gaps-rounded-git
```

### Step 4: Configuring rofi
```
yay -S rofi

# copy the config files
cd ~/dotfiles
stow -Svt ~ rofi
```

### Step 5: Configuring alacritty
```
# copy the config files
cd ~/dotfiles
stow -Svt ~ alacritty

yay -S noto-fonts-emoji
```

### Step 6: Configuring dunst
```
yay -S dunst-git

# copy the config files
cd ~/dotfiles
stow -Svt ~ dunst
```

### Step 7: Configuring fish
```
sudo pacman -S fish
curl -L https://get.oh-my.fish | fish
```

### Step 8: Configuring zsh
```
sudo pacman -S zsh

#install ohmyzsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# copy the config files
cd ~/dotfiles
stow -Svt ~ zsh
```

### Step -: Configuring vim and neovim

### Step -: Configuring VSCode

### Step -: Customizing zsh with custom prompt

### Step -: Setting up a lockscreen
I would use light-dm as locker

```
dm-tool lock
```

### Step -: Customizing lightdm

### Step -: Configuring tmux


text:
---
title: rand() - Azure Data Explorer | Microsoft Docs
description: This article describes rand() in Azure Data Explorer.
services: data-explorer
author: orspod
ms.author: orspodek
ms.reviewer: rkarlin
ms.service: data-explorer
ms.topic: reference
ms.date: 02/13/2020
---
# rand()

Returns a random number.

```kusto
rand()
rand(1000)
```

## Syntax

* `rand()` - returns a value of type `real`
  with a uniform distribution in the range [0.0, 1.0).
* `rand(` *N* `)` - returns a value of type `real`
  chosen with a uniform distribution from the set {0.0, 1.0, ..., *N* - 1}.

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
---
layout: post
title: The One With Github Pages
categories: []
tags: [setup, github-pages, jekyll]
description: GitHub Pages is designed to host personal, organization, or project pages directly from a GitHub repository.
cover: "/assets/images/github.png"
cover_source: "http://incurs.us/sites/default/files/2016-07/github-wallpaper-1.png"
comments: true
---

[GitHub Pages](https://pages.github.com/){:target="_blank"} is a web hosting service offered by [GitHub](https://github.com/){:target="_blank"} for hosting **static web pages** for GitHub users, user blogs, project documentation, or even whole books.
It is integrated with the [Jekyll](https://jekyllrb.com/){:target="_blank"} software for static web site and blog generation. The Jekyll source pages for a web site can be stored on GitHub as a Git repository, and when the repository is updated, github servers will automatically regenerate the site.
GitHub Pages was launched in late 2008. As with the rest of GitHub, it includes both free and paid tiers of service, instead of being supported by web advertising. Web sites generated through this service are hosted either as subdomains of the github.io domain, or as **custom domains** bought through a third-party domain name registrars.

Steps for setup:
* **Fork** this [repository](https://github.com/shams-sam/github-page-v1).
* **Update** repository name to `<user_name>.github.io`.
* **Customize** `_config.yml` to match user credentials.
* In `_includes/comments.html` **edit** `disqus_shortname`.
* **Update** `index.html` bio.
* **Commit** the changes.
* Done!

This site is build on top of the customizations by [psteadman](https://github.com/psteadman){:target="_blank"} on [**lanyon**](https://github.com/poole/lanyon){:target="_blank"} theme which derives from [**poole**](https://github.com/poole){:target="_blank"}.
Head over to the post [Using Jekyll, Poole and Lanyon to setup my github user page](http://patricksteadman.ca/2014/08/04/lanyonsetup/){:target="_blank"} for further references.

Additions:
* Added [**MathJax**](http://docs.mathjax.org/){:target="_blank"} for adding equations.
* Added Facebook Sidebar Icon using [**font-awesome**](http://fontawesome.io/).
* Added Search bar to search through the posts using [**Tipue Search**](https://github.com/jekylltools/jekyll-tipue-search).
* Added [**Social sharing buttons**](https://mycyberuniverse.com/web/social-media-share-bar-jekyll-blog-website.html) for posts sharing on platforms like Reddit, Facebook etc.
* Added [**Typed.js**](https://github.com/mattboldt/typed.js/) developed by [Matt Boldt](https://www.mattboldt.com) for text typing using javascript.
* Added [**Travis CI** Build and Deployment](https://docs.travis-ci.com/user/deployment/pages/) as it helps debug issues in deployment easier.

## REFERENCES:

[Github Pages - Wikipedia](https://en.wikipedia.org/wiki/GitHub_Pages){:target="_blank"}

[Using Jekyll, Poole and Lanyon to setup my github user page](http://patricksteadman.ca/2014/08/04/lanyonsetup/){:target="_blank"}

license: MIT

gha_language: HTML

gha_license_id: MIT


text:
# encrypt

This is a learning exsample for encrypt and decrypt with RSA by Python.

## Getting Started

```
git clone git@github.com:yamamuteki/encrypt.git
cd encrypt
pip install -r requirements.txt
ssh-keygen -f rsa_key -t rsa -b 4096
```

### Use with local Python

```
echo 'hello world!' | python encrypt.py | python decrypt.py
```

### Use with Docker

```
docker run -v $(pwd):/home python:3.9 /bin/bash -c "cd home && pip install -r requirements.txt && echo 'hello world!' | python encrypt.py | python decrypt.py"
```

## License

This project is licensed under the MIT License - see the LICENSE.md file for details.

repository: yamamuteki/encrypt

branch_name: refs/heads/main

gha_language: Python

repo_name: yamamuteki/encrypt


text:
# binarydist

[![GoDoc](https://godoc.org/github.com/dlsniper/binarydist?status.svg)](https://godoc.org/github.com/dlsniper/binarydist)
[![Circle CI](https://circleci.com/gh/dlsniper/binarydist.svg?style=svg&circle-token=abf9b5aa884649969ca6906d22ef61f8435c5375)](https://circleci.com/gh/dlsniper/binarydist)
[![Coverage Status](https://coveralls.io/repos/dlsniper/binarydist/badge.svg?branch=master&service=github)](https://coveralls.io/github/dlsniper/binarydist?branch=master)

Package binarydist implements binary diff and patch as described on
<http://www.daemonology.net/bsdiff/>. It reads and writes files
compatible with the tools there.

Documentation at <https://godoc.org/github.com/dlsniper/binarydist>.

The original implementation was created by <https://github.com/kr>.
It did not allowed for implementing a different compressor to enable
other use cases as such I had to change the implementation to support
this.

### TODO

- [ ] change the implementation from using package wide functions to
 structure wide functions

repository: dlsniper/binarydist

repo_name: dlsniper/binarydist


text:
# Contribution Guide

## How to contribute

### Issues

You can freely create an issue using the following links:

- Report and fixes for bugs and performance issues [[Here]](https://github.com/akinomyoga/ble.sh/issues/new?template=bug_report.md)
- Questions on usage [[Here]](https://github.com/akinomyoga/ble.sh/issues/new?template=feature_request.md)
- Feature request [[Here]](https://github.com/akinomyoga/ble.sh/issues/new?template=help.md)
- Others (suggestions, projects, discussion, complaints, news, information or anything) [[Here]](https://github.com/akinomyoga/ble.sh/issues/new?template=free_style.md)

### Pull requests

We always welcome following types of pull requests. Any changes will be considered to be provided under the BSD 3-Clause License.
If you do not know whether your changes would be appropriate for merge, please feel free to create a pull request and let us talk with each other!

- Better translation to English, typo fixes
- Fixes, optimization, test cases
- New features
- New color themes ... We accept new themes in [`contrib`](https://github.com/akinomyoga/blesh-contrib/pulls) repository.
- Others

### Wiki

You can freely edit [wiki pages](https://github.com/akinomyoga/ble.sh/wiki).

- Translations
- Typo fixes
- Create new pages

## For package maintainers

If you are a package maintainer for a repository of Linux distribution, etc.
you may provide a package-specific setting by preparing
a file `/path/to/blesh/lib/_package.sh` (e.g. `/usr/share/blesh/lib/_package.sh`)
which will be sourced after the load of `ble.sh` just before sourcing user's configuration (`~/.blerc`).

- In the file, the shell variable `_ble_base_package_type=TYPE` should be
   set up to have a repository-specific name (such as `AUR`).

- The function named `ble/base/package:TYPE/update` (where `TYPE`
  matches with a value assigned to `_ble_base_package_type`) may be
  provided to define a custom updating procedure.  The exit status of the function can be
  - `0` ... when the update successed
  - `6` ... when the update was skipped because the package was up to date.
  - `125` ... when it wants to fallback to the built-in updating procedure of `ble.sh`.
  - Other ... when the update failed

An example `lib/_package.sh` might be

```bash
_ble_base_package_type=apt

function ble/base/package:apt/update {
  sudo apt upgrade blesh
}
```

You can also find a real example for AUR (Arch User Repository) [here](https://aur.archlinux.org/cgit/aur.git/tree/blesh-update.sh?h=blesh-git).

## Summary of codebase

The core script file `ble.sh` is generated by combining the following files:

- `ble.pp` ... Basic initialiation
- `src/def.sh` ... Prototype definitions
- `src/util.sh` ... Basic utility functions
- `src/decode.sh` ... User-input decoder and keybindings
- `src/color.sh` ... Terminal graphic attributes
- `src/canvas.sh` ... Terminal layout engine
  - `src/canvas.emoji.sh` ... Emoji database
- `src/history.sh` ... Command history management
- `src/edit.sh` ... Line editor
- `src/benchmark.sh` ... Measure processing time
- `lib/core-completion.sh` ... Prototype definition for completions
- `lib/core-syntax.sh` ... Prototype definitions for syntax analyzer

Useful features are implemented in separate modules:

- `lib/keymap.vi.sh` ... Vim mode
  - `lib/vim-arpeggio.sh` ... `vim-arpeggio`-like plugin
  - `lib/vim-surround.sh` ... `vim-surround`-like plugin
- `lib/keymap.emacs.sh` ... Emacs mode
- `lib/core-syntax.sh` ... Shell parser and syntax highlighting
  - `lib/core-syntax-ctx.def` ... Definition of parser states
- `lib/core-complete.sh` ... Completions including `menu-complete`, `auto-complete`, `menu-filter`, `dabbrev`, `sabbrev`, etc.

The following files are initialization scripts:

- `lib/init-term.sh` ... Initialize terminal escape sequences (host-to-terminal, i.e. control sequences)
- `lib/init-cmap.sh` ... Initialize terminal escape sequences (terminal-to-host, i.e. key sequences)
- `lib/init-bind.sh` ... Initialize readline attacher
- `lib/init-msys1.sh` ... Workaround for MSYS1 with broken pipes
  - `lib/init-msys1-helper.c` ... Helper C program for the workaround of broken pipes

The contrib repository contains configurations built on top of the `ble.sh` framework

- `contrib/config/*.bash` are specific configurations whose details may depend on the user's preferences. These are expected to work just by `ble-import` but at the same time serve as examples for the user's personal versions.
- `contrib/sample/*.bash` are examples to explain interfaces for configurations.  These are just explanation of the interface so would not actually function.
- `contrib/airline/*.bash` are the themes for `vim-airline`.
- `contrib/integration/*.bash` are codes needed for the adjustments with other framework.
- `contrib/*.bash` are other miscellaneous configurations. Usually one needs additional configuration after `ble-import`. These files may be moved to another directory in the future.

## Tests

Tests can be run by one of the following commands:

```bash
$ make check
$ make check-all
$ bash out/ble.sh --test

```

Currently test coverage is very small
partly because the testing for interactive behavior and terminal rendering results is hard.
Nevertheless, the tests are defined in the following files:

- `lib/core-test.sh` ... Library for tests
- `lib/test-bash.sh`
- `lib/test-main.sh`
- `lib/test-util.sh`
- `lib/test-canvas.sh`
- `lib/test-edit.sh`
- `lib/test-complete.sh`
- `lib/test-syntax.sh`

## Coding styles

These styles are not required for the initial PR as these are too complicated.
The maintainer(s) will apply the styles before merging.
Nevertheless, it would be useful to follow the styles when you are going to submit PRs many times.

### Naming convention for functions

The function names roughly has the following structure, but the rule is ambiguous to some extent, and there are also many exceptions in the codebase.

```ebnf
function_name = (namespace '/')* function_basename ;

namespace = function_basename ;

function_basename = name ext?                        (* namespace function              *)
                  | class '.' name ext?              (* class method                    *)
                  | class '#' name ext?              (* instance method                 *)
                  | class '#' class '::' name ext?   (* instance method (override)      *)
                  | type ':' name ext? ;             (* customization point             *)

name = hyphenated_name extension                     (* public                          *)
     | '.' hyphenated_name ;                         (* private                         *)

ext = '.hook'                                        (* hook functions for blehook      *)
    | '.draw'                                        (* function operating on DRAW_BUFF *)
    | '.fib'                                         (* worker for ble/util/fiberchain  *)
    | '.proc'                                        (* callback functions              *)
    | '.impl' ;                                      (* internal implementation         *)
                                                     (* ... (and more extensions)       *)

class = name ;

type = hyphenated_name ;

hyphenated_name = (word '-')* word ;

word = /[_a-zA-Z0-9]+/ ;
```

The function names are basically hyphenated words (such as `foo-bar-baz` instead of `foo_bar_baz`, `fooBarBaz`, or `FooBarBaz`).

**Namespace**--The function names can be prefixed by namespaces of the form `<namespace>/`.
Except for the functions intended to be called from the command line or the user configuration, all the function should be defined in a namespace.
The interface of the functions defined in a namespace is subject to change in the future.
A function name can also be used as the namespace name for the helper functions to implement the function.
For the functions defined in external modules, the following namespace should be used to avoid conflicts:

| Types                                               | Namespace                              |
|:----------------------------------------------------|----------------------------------------|
| `contrib/*.bash`                                    | `ble/contrib/<modulename>`             |
| `contrib/config/*.bash`                             | `ble/contrib/config:<modulename>`      |
| `contrib/integration/*.bash`                        | `ble/contrib/integration:<modulename>` |
| User's public config                                | e.g. `<user>`                          |
| User's private config                               | e.g. `<user>` or `my`                  |
| User's private config in Bash initialization file   | e.g. `<user>`, `my` or `bashrc`        |
| User's private config in ble.sh initialization file | e.g. `<user>`, `my` or `blerc`         |

**Private**--The function basename started with `.` is considered private within the namespace. All the other functions are public.

**Method**--The function basename of the form `<class>#<name>` is considered an instance method.
The function basename of the form `<class>.<name>` is considered a class method.
The difference between the two is the latter assumes a single global state while the former assumes that an instance is specified by the first argument or by other means.
The way to specify the instance depends on the class.
For example, `ble/array#*` receives the variable name as the first argument while `ble/string#*` directly receives the string value as the first argument.
For `ble/textarea#*`, the target instance is selected by the shell variable `_ble_textarea_panel`.
The function basename of the form `<class1>#<class2>::<name>` is used to define a virtual function called by the base class `<class2>` at the side of the derived class `<class1>`.

**Customization point**--The function basename of the form `<type>:<name>` is used to provide the customization point for dynamic values.
This function is typically called as `<type>:"$var"` with `var` contains a value that depends on the context including the currently selected class, user configuration, etc.

**Extension**--The extension `<ext>` can be used to mark the specific types of functions.

### Naming convention for variables

The variable names roughly have the following structure.

```ebnf
local_variable_name = varname
                    | '__ble_' varname
                    | '_ble_local_' varname ;

global_variable_name = ('_' namespace)* '_' varname ;

namespace = word ;
varname = (word '_')* word ;
word = /[a-zA-Z0-9]+/ ;
```

The variable names are basically lowercase underscored words such as `foo_bar_baz` (instead of `fooBarBaz` or `FooBarBaz`).
Some global constants and the exported variables have all-uppercase names, but the lowercase should be basically used.

**Local variables**--The local variables that are only used in the declared function should be basically unprefixed by an underscore.
When the function reads/returns a value through an arbitrary name of in/out variables,
the local variable declared within the function should be prefixed by `__ble_` or `_ble_local_` to avoid the name conflicts between the local and in/out variables.

**Global variables**--All the global variables, except for the variables that are intended to be directly modified from the command line, should be prefixed by `_`.
Currently, there are no variables intended to be directly modified from the command line[Note 1].
The variables defined in external modules should be namespaced by the module name.
The variables in modules in the `contrib` repository should have the prefix `_ble_contrib_<module_name>_`

- [Note 1] In the initial implementation of ble.sh, the ble.sh options are provided as shell variables `bleopt_*`.
As remnant or for the backward compatibility, the values of ble.sh options are still stored in the variables of the name `bleopt_*`,
but these variables for the ble.sh options will be renamed in the future.

### Function interface

The success/failure states should be returned by the exit status.

**`ret`**--All the other values should be basically returned through shell variables.
This is because, if a function returned its result through the standard output,
the caller would need to capture the results by a command substitution which involves a fork of a subshell and thus is slow.
Here, the efficiency is the primary interest, so there are exceptions where the standard output can be more efficient:
For examples, when the output needs to be saved to a file for later use or to pass it to a different process,
or when the output needs to be processed by the external commands that reads the standard input.
The variable name to return a value should be basically `ret` unless the purpose of function is to store values.
When the function basename has the form `get-<name>`, one should consider retruning the result through the shell variable named `<name>`.
When a function returning multiple values is called from many places, the function may receive an array name as the first argument and stores the result in the specified array.
When the out variable names are specified in the arguments, they should come first in the list of the arguments.

**`opts`**--The argument position should be basically fixed (e.g., never shifted by optional arguments like `-f` or `-o name`).
The optional arguments can be specified by a colon-separated fields (like `SHELLOPTS` or `BASHOPTS`)
instead of the unix-style flags and options like `-f` and `-o optarg`.
This is because usually the parsing of the unix-style arguments (with or without `getopts`) is slow.
The local variable that receives the colon-separated option typically has the name `opts` or `*opts` (e.g. `local opts=$2`).
A single option has the form `name` or `name=value`,
where `name` should be a hyphenated words like `foo-bar-baz`.
The former form without the value is called a flag option.
One can test a flag option by `[[ :$opts: == *:flag-name:* ]]`.
An option of the form `name=value` can be matched by `ble/opts#extract-first-optarg`, `ble/opts#extract-last-optarg`, or `ble/opts#extract-all-optargs`.
The function `ble/opts#has` can be used to test if either of `name` or `name=value` is contained

**`$*`**--The functions that receive a string should not allow a variable number of arguments that are joined inside the function.
A variable number of arguments should be only used when each argument is really processed separatedly.
If necessary, the joining should be performed at the caller side.
This is because `IFS` in the caller context affects the joining `$*`, so the handling of `IFS` should be properly done at the caller side.
Another reason is for the future extension, e.g., to add another optional argument.

### Variable declarations

Local variables should be declared by `local` (instead of `declare` or `typeset`).
Variables should be always initialized before referencing their values. This is because uninitialized variables can have random values when `shopt -s localvar_inherit` is turned on.

The declaration and the initialization of an array variable should be separated as far as the initializer values contain any expansions or any spaces.
There is a bug in Bash 3.0 that the values are separated by whitespaces even when the values are quoted.
When the declaration and the initialization of an array variable are made in a single command, the option `-a` needs to be specified.
Without `-a`, the entire list `(...)` including the surrounding parens will be treated as a scalar string in Bash 3.0.

```bash
local v; v=("$var")
local -a v=()

# The following may not work as expected
# local v=()         # Bash 3.0 will initialize a scalar with the value v='()'  #D0184
# local -a v=("a b") # Bash 3.0 will split it into the two elements "a" and "b" #D0525
```

Defining local readonly variables should be avoided
because they will hide global variables from the utilities `ble/variable#is-global`, `ble/util/print-global-definitions`, etc.
Global readonly variables should never be defined.
The background is described in the Limitation section of README.

### Conditional commands `[[ ... ]]`

Do not use `[ ... ]` or `test` unless it is intended to be a POSIX script. Always use `[[ ... ]]`.

Use `[[ word ]]` and `[[ ! word ]]` instead of `[[ -n word ]]` and `[[ -z word ]]`.

Use `==` instead of the operator `=` inside conditional commands.

**Quoting**--The right-hand sides of `==` and `!=` inside conditional commands `[[ ... ]]` should be properly quoted.
The right-hand sides of `=~` inside the conditional commands `[[ ... ]]` should be specified by a single parameter expansion
as `[[ word =~ $rex ]]`, or one can use `ble/string#match 'word' "$rex"` instead.
In other contexts, the arguments of the conditional command should not be quoted
unless raw special characters ``[[:space:]|&;<>\`"$]`` are contained in the argument.

**No `-eq` etc**--Basically use arithmetic commands `((expr))`
instead of the operators `-eq`, `-ne`, `-gt`, `-ge`, `-lt`, and `-le` of the conditional command.
They might be used when the test is used as a part of complicated conditions in the conditional commands.
For example, `[[ -f $file || $word && word -eq 0 ]]` can be used instead of `[[ -f $file ]] || { [[ $word ]] && ((word == 0)); }` becausing sticking with the arithmetic command would unnecessarily complicate the code in this case.

### Other styles

**Function definition**--There are two forms of function definitions, the POSIX style `func()` and the ksh style `functino func`, as well as the mixed form.
We always use the ksh style of the function definition.
The reasons are that it is easier to search by the keyword `function ` and that it is protected by the aliases of the same name as the function (unless the user defines an alias with the same name as the keyword `function`).
The function body is always the compound command `{ ... }` (instead of any other compound commands such as `( ... )`, `for`, `if`, etc.), and the opening brace `{` is placed on the first line.

```bash
function function-name {
  : do_something
}
```

**`ble/util/print`**--Use `ble/util/print` instead of `echo`. Use `ble/util/put` instead of `echo -n`.
The control characters should be directly specified by the escape string literal `$'...'` instead of relying on the conversion by `echo -e`.
This is because the builtin `echo` can change its behavior depending on the shell option `shopt -s xpg_echo`, where the backslashes in the arguments might have special meaning.
`ble.sh` is intended to work under any possible user options.

**Quote/unquote**--The arguments where the word splitting and pathname expansions can take place need to be always quoted.
When the subject word of `case` statement and the right-hand sides of variable assignments
(including those specified to assignment builtins `declare`, `typeset`, `local`, `export`, and `readonly`)
contains `$*`, `${arr[*]}`, or raw special characters ``[[:space:]|&;<>\`"$]``, they need to be quoted.
In other contexts, the subject word of `case` and the right-hand sides of variable assignments should not be quoted.
In these contexts, the word splitting and pathname expansions will never happen, so the quoting is unnecessary.

Array subscripts are arithmetic context, so the arithmetic expansions `$((expr))` inside the array subscripts are redundant. One should simply write it as `arr[expr]` instead of `arr[$((expr))]`.

**`ble/util/assign`**--Use `ble/util/assign`, `ble/util/assign-array`, and `ble/util/assign-words` instead of `var=$(cmd)`, `mapfile -t var <<< "$(cmd)"`, and `var=($(cmd))`, respectively.
The command substitutions `$(...)` are slow because they involve the forks of subshells.

**External commands**--Implement it using built-in Bash features as much as possible.
If the same result can be obtained by built-in Bash features efficiently, do not use the external commands.
When the external command is used, first freeeze the path by calling `ble/bin#freeze-utility-path '<cmd>'` and call the commands through `ble/bin/<cmd>`.
Or save the path of the external command in a variable, and call the command through the variable as `"$_saved_cmd" args...`.
The POSIX commands should be basically used. If non-POSIX commands are used, a POSIX fallback should be always prepared.
Please combine multiple calls of external commands into a single call of the command as much as possible.
Usually, a single call of `sed` and `awk` are preferred over the chain of simple commands.

gha_language: Shell


text:
---
title: "Using JSX with TypeScript"
author: 'blog.mgechev.com'
date: '2015-07-05'
slug: using-jsx-with-typescript
link: https://blog.mgechev.com/2015/07/05/using-jsx-react-with-typescript/
categories:
- bloglink
tags:
  - python
  - modeling
  - blogmgechevcom
---

JavaScript is a weird language although, we love it the way it is. However, I've had quite a painful experience working on big JavaScript projects. It was painful in the same way it gets painful working on huge Ruby, Python, PHP projects. Once you have code base above 10-15k lines of code and you decide to do some refactoring..[... <i class="fas fa-external-link-alt"></i>](https://blog.mgechev.com/2015/07/05/using-jsx-react-with-typescript/)

repository: mkearney/data-scribers

repo_name: mkearney/data-scribers


text:
# Alfrodull
Alfrodull is a utility that controls lights based on the a computers events.

The lights can be turned off when the computer sleepd, and turn on when the computer wakes up. The original use case was to attach an led strip behind the monitor that turn on and off as the display does. But much more can be doen as additional events can easily be added. For example blinking the lights when notifications are received or tracking CPU usage and warning when it passes a threshold.

Right now the only supported devices are those from [blinksticks](https://www.blinkstick.com/). More can be added if requested and I can get ahold of them.

Alfrodull only works on Linux right now as all of the events uses DBUS notifications to react to events. Support for Windows could be added in the future but would require some other notification service.

## Install
```bash
pip install alfrodull
```

## Usage
Simply start alfrodull and pass a configuration file path as input.
```bash
alfrodull config.yml
```
Alfrodull could for example be started in xinit or i3wm config.

## Configuration
Alfrodull is configured with a file, this is where the event, animation and, color are specified. Colors are defined as hex values ex. `#ff00ff`, the values will be checked when the program is started and throw an exception if they can't be parsed. Passing a null value to the color is parsed as turning off the lights. Below are the currently supported events and animations that can be used.

| Event | Description |
| --- | --- |
| Init | After the applicationn is first run |
| Shutdown | Before the computer turns off |
| Sleep | Before the computer goes to sleep |
| Wakeup | After the computer wakes up |

| Effect | Description |
| --- | --- |
| Fade | Fades from the current color or if the color is null turn off. |
| Outside In | Starts from the outside and changes light one by one to the inside. |
| Inside Out | Opposite of Outside In. |

```yml
device: blinkstick
events:
  - type: "Init"
    animation:
      type: "Fade"
      color: "#ffffff"
  - type: "Sleep"
    animation:
      type: "Inside Out"
      color: "#000000"
  - type: "Wakeup"
    animation:
      type: "Outside In"
      color: "#ffffff"
```

## License
This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.

repository: phillebaba/alfrodull

repo_name: phillebaba/alfrodull


text:
---
layout: post
title: 'Jekyll Part 02: Your First Post'
published: true
categories: ['blogging', 'jekyll']
date: 2015-02-05
series: blogging-with-jekyll
excerpt: |
    Welcome the continuing series on using Jekyll.  In this tutorial we will go through making your first blog post.

    ## Overview

    We will go through all of the steps to create a new post, add metadata such as title/categories/tags/date, and then make it live on the site.

---

Welcome the continuing series on using Jekyll.  In this tutorial we will go through making your first blog post.

## Overview

We will go through all of the steps to create a new post, add metadata such as title/categories/tags/date, and then make it live on the site.

## Section 1: Creating the file

Thr first step is to create a new file to hold the content of the blog post.  In Jekyll all of the blog post are markdown files and are stored in the _post directory.    When you commit this file to Github, it will be compiled into a static html page.

The filename is in the format of year-month-day-title-separated-by-dashes.md.

	2015-02-17-my-first-post.md

Go ahead and create your file now.

1. To create a file open a web browser and navigate to your [username.github.io repository.
2. Go into the _post directory and click the + icon to add a new file.
3. Name the file yyyy-mm-dd-my-first-post.md where yyyy = 4digit year,  mm = 2 digit month, and dd = 2 digit day of montmonth.
4. Head to the next section and fill out the metadata about the post (ie: title, date, is published, categories, etc)

## Section 2: Creating metadata

Now we need to define some information about our blog post.  All of the information such as title, is published,  categories, publish date, etc are stored at the top of the file in what is called Front Matter.

To define the front matter section you have a line with 3 dashes in it and then repeat this same line to signal the end of the front matter section.

Below are common metadata you will want to fill out.

- layout:  is the name of the layout  from the _layouts directory.  If followed part 1 and cloned the jekyll-now repository, then the name is post.
- title:  the title of the blog post that will showbon the site.  Should be in quotes to avoid conflict with front matter parameter.
- published: true or false.  Determines  if the post shows  on the website or not.
- date: date of the post.  this is optional and if not defined will use date in filename.
- categories: list of categories.  comma delimited.  put in quotes for multi word categories.  optional but recommended.
- tags: list of tags that would be used to build a tag cloud.  optional but recommended.

### Sample Front Matter:
	---
	layout: post
	title: Your First Post
	published: false
	date: 2015-02-01
	categories: [blogging]
	tags: [blogging]
	---

Now on to creating actual content in your post.

## Section 3:  Creating content

The content of the post will be written in markdown and will be directly below the front matter section .

 Below are common markdown tags that you will want to use.  headers, lists, bold, bullets, links and code highlighting.

**Common Markdown Tags**

####Headers

A #  starting  a line indicates to makebitba header and the number # indicates  the size of the header tag.

	#  = 	h1
	## = h2
	and so on up the an h6

**examples**

#  h1

## h2

## h3

### h4

#### h5

#### h6

#### Numbered list  or Bullets

For bullets: start a line with a * or -.

	* sample list
	* next bullet

* sample list
* next bullet

For numbered list start with a 1 or the number you want to start with.

	1. sample ordered list
	2. number 2

1. sample ordered list
2. number 2

#### Bold

surround  the text you to build with 2 ** and then put 2 more after the text  to end the bold.

	**sample bold**

**sample bold**

#### Links

link to other pages:

	[link name display](http://myurl.com)

[link name display](http://myurl.com)

### Code Highlighting

There are 2 ways: tab the line in and it will group the text like the examples above.
or use the highlighter markup

{% highlight text %}
{% raw %}
{% highlight c# %}
// some c# code
var a = "bad variable name"
{% endhighlight %}
{% endraw %}
{% endhighlight %}

## Highlighting text without the code highlighting

Start the line with a tab and it will automatically do it for you.

	you will get text like this if you start the line with a tab.

## Further Reading on Markdown

Github documentation on their markdown:  [https://help.github.com/articles/github-flavored-markdown/](https://help.github.com/articles/github-flavored-markdown/).

## Section 4:  Saving as draft

Most of the time you are not going to write and publish the blog post in one sitting but you need to save your work without it showing up in the website.  This is called saving a draft and it is super simple to do.  By setting the front matter published tag to false it will tell jekyll to not publish it.

	---
	other front matter tags
	published: false
	---

You can also create a drafts folder and save the file in the but if you do that then you will need to move the file to the _post folder when you are ready to publish.

## Section  5: Publishing post

Publishing a post is as simple as changing the front matter published to true and committing the change to the github repository.

	---
	other front matter tags
	published: true
	---

Github will take care of the conversion from markdown to an html page.  This should happen automatically within a minute and show up on the blog home page at the top.

If it doesn't show up then check your email that you registered on github with to see if there was a jekyll compile error email.

## Conclusion

This lesson is one of the key lessons as you need to kow how to create new blog post.  Creating new blog post is really easy with Jekyll and a little bit of markdown.  Once you learn the different markdown tags, you will be writing blog post in no time at all.

See you in the next lesson, where we will discuss how to add the ability to comment on blog post.