| Perl Function / Method | Namespace (eg. Package) | Command / Syscall / C Function | |
|---|---|---|---|
| compare | File::Compare | cmp(1) | |
| catdir | File::Spec | cat(1) | |
| catfile | File::Spec | cat(1) | |
| basename | File::Basename | basename(1) | |
| dirname | File::Basename | dirname(1) | |
| grep | CORE | grep(1) | |
| find | File::Find | find(1) | |
| s/// | CORE | sed(1) | |
| tr// | CORE | tr(1) |
How to get Pull Requests data using Github in the browser, or using the API to allow for automating reporting or building in values into a website.
| use v5.16; | |
| use warnings; | |
| package HTTP::Tiny::nc; | |
| use parent 'HTTP::Tiny'; | |
| our $VERSION = v0.0.3; | |
| # Copyright (c) 2019-2023 Andrew Hewus Fresh <afresh1@openbsd.org> | |
| # | |
| # Permission to use, copy, modify, and distribute this software for any |
Often there is the question to get the download URL for an asset (e.g. a setup-file) of the latest release of a project. In my case I provide an executable, which includes the version number in its name, like this:
project-X.Y.Z-setup.exe
together with the source as ZIP- and Tarball-archive. Now to get the download URLs of the assets and source archives using the GitHub API one can get and process this URL (replacing USER and PROJECT with the GitHub user account and projectname accordingly):
| // Examples for using socat (and filan) | |
| //"$" means normal user, "#" requires privileges, "//" starts a comment | |
| /////////////////////////////////////////////////////////////////////////////// | |
| // similar to netcat | |
| // connect to 10.1.1.1 on port 80 and relay to and from stdio |
Hello!
This document talks about how to use MacPorts to make a macOS installer packages that will install multiple MacPorts ports onto a system.
MacPorts is a project which takes open-source software and builds it for macOS. It takes care of the work of identifying and patching any macOS-specific problems, working out how best to do the build, etc..
Normally, you install MacPorts on your local system, and use the Terminal to install ports (a port is an individual software offering). However, it is also possible to use MacPorts to build macOS installer packages (.pkg files). MacPorts can also bundle multiple ports into a single package (an .mpkg file), so you can install multiple ports in a single action. The ability to make .mpkg files is useful, because ports typically depend on other ports in order to function properly.
This document describes the process for making .mpkg files, so that you can distribute them to systems.
I'm talking about this: http://stackoverflow.com/documentation/django
Compared to well written documentation, this kind of documentation is pretty bad. Yes, many projects have terrible documentation, and for them it might be an improvement, but for many that have good docs, this is a major step backwards.
Good documentation requires serious effort and organisation. It can't be achieved by throwing together lots of examples.
| #!/bin/bash | |
| #Quake on Bash on Ubuntu on Windows | |
| [[ `id -u` -eq 0 ]] || { echo "Must be root to run script, try running again with sudo"; exit 1; } | |
| #ensure Xming is installed | |
| if [ -f "/mnt/c/Program Files (x86)/Xming/Xming.exe" ] | |
| then | |
| echo "XMing is installed on Windows Filesystem, please ensure that it is running"; | |
| else |
