The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,227 other subscribers

Archive for the ‘bash’ Category

llamasoft/polyshell: A Bash/Batch/PowerShell polyglot!

Posted by jpluimers on 2023/03/16

PolyShell is a script that’s simultaneously valid in Bash, Windows Batch, and PowerShell (i.e. a polyglot).

[Wayback/Archive] llamasoft/polyshell: A Bash/Batch/PowerShell polyglot!

Need to check this out, as often I have scripts that have to go from one language to the other or vice versa.

Maybe it enables one language to bootstrap functionality in the other?

The quest

The above polyglot started with a quest to see if I can could include some PowerShell statements in a batch file with two goals:

  1. if the batch file started from the PowerShell command prompt, then execute the PowerShell code
  2. if the batch file started from the cmd.exe command prompt, then have it start PowerShell with the same command-line arguments

The reasoning is simple:

  1. PowerShell scripts will start from the PATH only when PowerShell is already running
  2. Batch files start from the path when either cmd.exe or PowerShell are running

Lots of users still live in the cmd.exe world, but PowerShell scripts are way more powerful, and since PowerShell is integrated in Windows since version 7, so having a batch file bootstrap PowerShell still makes sense.

Since my guess was about quoting parameters the right way, my initial search for the link below was [Wayback/Archive] powershell execute statement from batch file quoting – Google Search.

I have dug not yet into this, so there are still…

Many links to read

These should give me a good idea how to implement a polyglot batch file/PowerShell script.


Posted in *nix, *nix-tools, bash, bash, Batch-Files, Development, JavaScript/ECMAScript, Perl, Polyglot, Power User, PowerShell, Scripting, Software Development | Leave a Comment »

On my list of *n*x things to play with: script and ttyrec

Posted by jpluimers on 2023/01/26

Because of [Archive] PragmaticProgrammers on Twitter: “Helpful Unix trick: use script to log your session. …” / Twitter:


Read the rest of this entry »

Posted in *nix, *nix-tools, ash/dash, bash, bash, Batch-Files, Development, Power User, Scripting, Software Development | Leave a Comment »

Getting your public IP address from the command-line when http and https are blocked: use DNS

Posted by jpluimers on 2022/12/28

Years ago, I wrote Getting your public IP address from the command-line. All methods were http based, so were very easy to execute using cURL.

But then in autumn 2021, Chris Bensen wrote this cool little blog-post [Wayback/Archive] Chris Bensen: How do I find my router’s public IP Address from the command line?:

dig -4 TXT +short

At first sight, I thought it was uncool, as the command was quite long and there was no explanation of the dig command trick.

But then, knowing that dig is a DNS client, it occurred to me: this perfectly works when http and https are disabled by your firewall, but the DNS protocol works and gives the correct result:

# dig -4 TXT +short

This added the below commands and aliases to my tool chest for *nix based environments like Linux and MacOS (not sure yet about Windows yet :), but that still doesn’t explain why it worked. So I did some digging…


  • command:
    dig -4 TXT +short
  • command removing outer double quotes:
    dig -4 TXT +short | xargs
  • alias:
    alias "whatismyipv4_dns=dig -4 TXT +short | xargs"


  • command:
    dig -6 TXT +short
  • command removing outer double quotes:
    dig -6 TXT +short | xargs
  • alias:
    alias "whatismyipv6_dns=dig -6 TXT +short | xargs"

How it works

Let’s stick to dig and IPv4 as that not having IPv6 (regrettably still) is the most common situation today:

# dig -4 TXT +short

What it does is request the DNS TXT record of from the Google DNS server and returns the WAN IPv4 address used in the DNS request, which is for instance explained in [Wayback/Archive] What is the mechanics behind “dig TXT” : linuxadmin.

Since these are TXT records, dig will automatically double quote them, which xargs can remove (see below how and why):

# dig -4 TXT +short | xargs

The DNS query will fail when requesting the Google Public DNS servers or

# dig -4 TXT +short @

Or, with quotes removed (the -L 1 ensures that xargs performs the quote-pair removal action on each line):

# dig -4 TXT +short @ | xargs -L 1

This request is both slower than requesting the server and wrong.

The reason is that only understands the special hostname which instructs it to return the IP address of the requesting dig DNS client.

That returns a different IP address and an additional edns0-client-subnet with less accurate information is explained in an answer to [Wayback/Archive] linux – Getting the WAN IP: difference between HTTP and DNS – Stack Overflow by [Wayback/Archive] argaz referring to this cool post: [Wayback/Archive] Which CDNs support edns-client-subnet? – CDN Planet.

Not just any DNS server serving the domain

Since is part of the domain, the above works for any DNS server serving the domain (more on that domain: [Wayback/Archive] General DNS overview  |  Google Cloud).

Getting the list of DNS servers is similar to getting the list of MX servers which I explained in Getting the IP addresses of gmail MX servers, replacing MX record type (main exchange) with the NS record type (name server) and the domain with the domain:

# dig @ +short NS

The DNS server is a special one of the NS servers: it is the start of authority server, which you can query using the SOA record type that also gives slightly more details for this server:

# dig @ +short SOA 410477869 900 900 1800 60

The difference between using NS and SOA records with dig are explained in the [Wayback] dns – How do I find the authoritative name-server for a domain name? – Stack Overflow answer by [Wayback/Archive] bortzmeyer who also explains how to help figuring out SOA and NS discrepancies (note to self: check out the check_soa tool originally by Michael Fuhr (I could not find recent content of him, so he might have passed away) of which source code is now at [Wayback/Archive] Net-DNS/check_soa at master · NLnetLabs/Net-DNS).

So this works splendid as well using on my test system:

# dig -4 TXT +short | xargs

The xargs removes outer quotes removal trick

[Wayback/Archive] string – Shell script – remove first and last quote (“) from a variable – Stack Overflow (thanks quite anonymous [Wayback/Archive] user1587520):

> echo '"quoted"' | xargs

xargs uses echo as the default command if no command is provided and strips quotes from the input.

More on https versus DNS requests

Some notes are in [Wayback/Archive] How to get public IP address from Linux shell, but note the telnet trick now fails as is gone (latest live version was archived in the Wayback Machine in august 2019).



Posted in *nix, *nix-tools, Apple, bash, bash, Batch-Files, Communications Development, Development, DNS, Internet protocol suite, Linux, Mac, Mac OS X / OS X / MacOS, Power User, Scripting, Software Development, TCP | Leave a Comment »

Don’t fall for the golden hammer: avoid git empty commits, especially for kicking off parts of your CI/CD

Posted by jpluimers on 2022/08/16

A while back Kristian Köhntopp (isotopp) wrote a blog post after quite a Twitter argument where he poses against using git empty commits. I’m with Kris: don’t use them for anything, especially not for kicking off your CI/CD.

Basically his blog post is all about avoiding to think you have a golden hammer, and avoid falling for the Law of the instrument – Wikipedia.

Originally, Abraham Maslow said in 1966:

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

For me this has all to do with preventing technical debt: find the right tool to kick your CI/CD pipeline after part of that chain somehow malfunctioned is way better than polluting the commit history with empty commits.

His blog post: [Wayback/] Empty commits and other wrong tools for the job | Die wunderbare Welt von Isotopp

The most important bit in it:

And since we are talking about CI/CD pipelines: Don’t YAML them. Don’t JSON them. Don’t XML them.

Programming in any of these three is wrong use of tooling, and you should not do it.

  • YAML, JSON and XML are for declarative things.
  • Python, Go and Rust are for procedural things.
  • Bash is for interactive use only.

Use the proper tooling for the job. Be an engineer.

This very much reminds me of an Entwickler Konferenz keynote a long time ago, where Neal Ford made the point that most software engineers act very much unlike what is expected from traditional engineering way of operating where the engineer is both responsible and liable for his actions.

The start of the Twitter thread: [] Kristian Köhntopp on Twitter: “A lot of people right now that git is an API and triggering CI/CD pipelines with empty commits replaces the equivalent of a Kubernetes controller for their fragile pile of bash in git triggers. This is broken and begets more brokenness. Evidence:… “

The tweet that started the subtweet: [] Florian Haas on Twitter: “(For anyone wondering, what’s nice about this one is it works in any CI. So you don’t have to remember how to manually kick off a GitLab CI pipeline or GitHub Action or Zuul job, you just push an empty commit and off you go.)”

Other relevant tweets:

Yes, you want to avoid shell too (anything like for instance sh, ash, dash, bash or zsh), but you have to know it (and understand why to avoid it) as often it is the only interactive way to access systems from the console.

And of course Kris also wrote a big document on that too, which is available as full PDF (Wayback), full HTML (Wayback) and chaptered HTML Die UNIX Shell /bin/sh.

But more importantly, Kris wrote [Wayback/] Using Python to bash | Die wunderbare Welt von Isotopp which is about using Python to do things you might be tempted to do in the shell. It quotes

Shell is a thing you want to understand and then not use, because you learned to understand it.

which is from the German post in thread [Wayback/] Bashprogrammierung, wo gehts am besten los which quotes Kris’ 1998 message:

From kris Tue Sep 1 11:26:12 1998
From: kris
Newsgroups: de.comp.os.unix.misc
Subject: Re: Shell-Frage, find, xargs, kopieren von vielen Dateien
References: <6seh24$q9a$>
From: (Kristian Koehntopp)
Alignment: chaotic/neutral
X-Copyright: (C) Copyright 1987-1998 Kristian Koehntopp -- All rights
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit (Marc Haber) writes:
>mir ist das ganze Zeug mit der Shell, find, xargs und Konsorten noch
>reichlich verschlüsselt.

>xargs hin oder sollte ich besser ein Perlskript schreiben?

Verwende Perl. Shell will man koennen, dann aber nicht verwenden.



Posted in *nix, *nix-tools, ash/dash, ash/dash development, bash, bash, Conference Topics, Conferences, Continuous Integration, Development, DVCS - Distributed Version Control, Event, git, Power User, Scripting, sh, Sh Shell, Software Development, Source Code Management, Technical Debt | Leave a Comment »

Filezilla SFTP: figuring out the cause of “Connection timed out after 20 seconds of inactivity” part 2: about ((non-)?(interactive|login) ?){2} bash shells

Posted by jpluimers on 2022/05/12

Last year, I wrote about Filezilla: figuring out the cause of “Connection timed out after 20 seconds of inactivity” about sftp connection problems.

The solution there was to exclude part of bashrc with an if [Wayback] statement so bash would skip it during sftp, but not during ssh login:

[WayBack] linux – Use .bashrc without breaking sftp – Server Fault

  • From answer 1 (thanks [WayBack] Mike):

    Try doing this instead

    if [ "$SSH_TTY" ]
       source .bashc_real
  • From Answer 2 (thanks [WayBack] Insyte):

    A good trick for testing the cleanliness of your login environment is to ssh in with a command, which simulates the same way scp/sftp connect. For example: ssh myhost /bin/true will show you exactly what scp/sftp sees when they connect.

That caused some scripts not to be run when switching user, for instance by doing sudo su -.

The reason for that was that I forgot to put enough research in part of Answer 2, so I quote a few bits more of it (highlights and code markup mine):

… it’s worth pointing out that you can accomplish this carefully selecting which startup files to put the verbose stuff in. From the bash man page:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.

The sftp/scp tools start an interactive non-login shell, so .bashrc will be sourced.

For further reading, there is the underlying bash manual as a PDF file [Wayback] and html document tree [Wayback]. Note it is large (the PDF is 190 pages).

I find the easiest way to navigate around bash documentation through these links:

Types of shell invocations: to login or to non-login and to interactive or to non-interactive

Basically, from the above answer there are [] 4 types of shells (confirmed by these parts of the bash documentation: [Wayback] Section 6.1: Invoking-Bash and [Wayback] Section 6.2: Bash-Startup-Files):

  1. interactive login
  2. interactive non-login
  3. non-interactive login
  4. non-interactive non-login

And there are various means the shells can start (ssh, local console, …). The "$SSH_TTY" trick only checks interactive login via ssh, but fails to detect others.

So I did some digging for the correct information to log, which including the above are:

  • [Wayback] Section 4.3.1: The-Set-Builtin
    • -h Locate and remember (hash) commands as they are looked up for execution. This option is enabled by default.
    • -m Job control is enabled (see Job Control). All processes run in a separate process group. When a background job completes, the shell prints a line containing its exit status.
    • -B The shell will perform brace expansion (see Brace Expansion). This option is on by default.
    • -H Enable ‘!’ style history substitution (see History Interaction). This option is on by default for interactive shells.

    Note that in addition to this, there is the non-settable option i: The current shell is interactive (see the -i in section 6.1 below).

  • [Wayback] Section 4.3.2: The-Shopt-Builtin
    • login_shell The shell sets this option if it is started as a login shell (see Invoking Bash). The value may not be changed.
  • [Wayback] Section 6.1: Invoking-Bash

    There are several single-character options that may be supplied at invocation which are not available with the set builtin.

    • -i Force the shell to run interactively. Interactive shells are described in Interactive Shells.

    login shell is one whose first character of argument zero is ‘-’, or one invoked with the –login option.

  • [Wayback] Section 6.2: Bash-Startup-Files explains about these shell invocation types:
    • interactive login shell
    • interactive non-login shell
    • non-interactive shell
  • [Wayback] Section 6.3.1: Is-this-Shell-Interactive

    To determine within a startup script whether or not Bash is running interactively, test the value of the ‘-’ special parameter. It contains i when the shell is interactive. For example:

    case "$-" in
    *i*)    echo This shell is interactive ;;
    *)  echo This shell is not interactive ;;

    Alternatively, startup scripts may examine the variable PS1; it is unset in non-interactive shells, and set in interactive shells. Thus:

    if [ -z "$PS1" ]; then
            echo This shell is not interactive
            echo This shell is interactive

From theory to practice

After reading the above documentation links, I put the below code in the global .bashrc (which of course caused trouble with sftp, so I commented it out later):

echo "Option flags: '$-'"
echo "PS1: '$PS1'"
echo "shopt login_shell: '$(shopt login_shell)'"
echo "Parameter zero: '$0'"
[ "$SSH_TTY" ] ; echo "[ \"\$SSH_TTY\" ] outcome: $?"

And the output after these commands:

  1. ssh user@host
    Option flags: 'himBH'
    PS1: '\u@\h:\w> '
    shopt login_shell: 'login_shell     on'
    Parameter zero: '-bash'
    [ "$SSH_TTY" ] outcome: 0

    Verdict: interactive, login

  2. ssh user@host

    followed by

    sudo su -
    Option flags: 'himBH'
    PS1: '\[\]\h:\w #\[\] '
    shopt login_shell: 'login_shell     on'
    Parameter zero: '-bash'
    [ "$SSH_TTY" ] outcome: 1

    Verdict: interactive, login

  3. ssh user@host

    followed by

    Option flags: 'himBH'
    PS1: '\u@\h:\w> '
    shopt login_shell: 'login_shell     off'
    Parameter zero: 'bash'
    [ "$SSH_TTY" ] outcome: 0

    Verdict: interactive, non-login

  4. ssh user@host

    followed by

    sudo su -

    then by

    Option flags: 'himBH'
    PS1: '\[\]\h:\w #\[\] '
    shopt login_shell: 'login_shell     off'
    Parameter zero: 'bash'
    [ "$SSH_TTY" ] outcome: 1

    Verdict: interactive, non-login

  5. ssh user@host /bin/true
    Option flags: 'hBc'
    PS1: ''
    shopt login_shell: 'login_shell     off'
    Parameter zero: 'bash'
    [ "$SSH_TTY" ] outcome: 1

    Verdict: non-interactive, non-login

The final one is what for instance sftp will see. It excludes the non-interactive mark in the shopt option flags.

Modifications to my .bashrc file

Since the [Wayback] test for "$SSH_TTY" is inconsistent with the login being interactive, I modified the .bashrc section

if [ "$SSH_TTY" ]
   source .bashc_real

to become

if [[ $- =~ i ]]
   # only during interactive login shells
   source .bashc_real

I know the [[...]] over test shorthand [...] is a bashism, see [Wayback] if statement – Is double square brackets [[ ]] preferable over single square brackets [ ] in Bash? – Stack Overflow for why I like it.

More relevant documentation

I based the above changes not only on the mentioned StackOverflow post, but also doing some more Googling revealing these useful documentation and question/answer links:

  • [Wayback] Section Conditional Constructs; [[ expression ]]


    [[ expression ]]

    Return a status of 0 or 1 depending on the evaluation of the conditional expression expression. Expressions are composed of the primaries described below in Bash Conditional Expressions. Word splitting and filename expansion are not performed on the words between the [[ and ]]; tilde expansion, parameter and variable expansion, arithmetic expansion, command substitution, process substitution, and quote removal are performed. Conditional operators such as ‘-f’ must be unquoted to be recognized as primaries.

    An additional binary operator, ‘=~’, is available, with the same precedence as ‘==’ and ‘!=’. When it is used, the string to the right of the operator is considered a POSIX extended regular expression and matched accordingly (using the POSIX regcomp and regexec interfaces usually described in regex(3)). The return value is 0 if the string matches the pattern, and 1 otherwise. If the regular expression is syntactically incorrect, the conditional expression’s return value is 2.

  • [Wayback] Section 4.1: Bourne Shell Builtins; test or [...] (Bash Reference Manual)
    test expr

    Evaluate a conditional expression expr and return a status of 0 (true) or 1 (false). Each operator and operand must be a separate argument. Expressions are composed of the primaries described below in Bash Conditional Expressionstest does not accept any options, nor does it accept and ignore an argument of -- as signifying the end of options.

    When the [ form is used, the last argument to the command must be a ].

  • [Wayback] bash – What are the special dollar sign shell variables? – Stack Overflow (thanks [Wayback] kojiro!):
    • $1$2$3, … are the positional parameters.
    • "$@" is an array-like construct of all positional parameters, {$1, $2, $3 ...}.
    • "$*" is the IFS expansion of all positional parameters, $1 $2 $3 ....
    • $# is the number of positional parameters.
    • $- current options set for the shell.
    • $$ pid of the current shell (not subshell).
    • $_ most recent parameter (or the abs path of the command to start the current shell immediately after startup).
    • $IFS is the (input) field separator.
    • $? is the most recent foreground pipeline exit status.
    • $! is the PID of the most recent background command.
    • $0 is the name of the shell or shell script.

    Most of the above can be found under Special Parameters in the Bash Reference Manual. There are all the environment variables set by the shell.

    For a comprehensive index, please see the Reference Manual Variable Index.

  • [Wayback] bash – Differentiate Interactive login and non-interactive non-login shell – Ask Ubuntu (thanks [Wayback] terdon)

    Briefly (see here for more details), with examples:

    • interactive login shell: You log into a remote computer via, for example ssh. Alternatively, you drop to a tty on your local machine (Ctrl+Alt+F1) and log in there.
    • interactive non-login shell: Open a new terminal.
    • non-interactive non-login shell: Run a script. All scripts run in their own subshell and this shell is not interactive. It only opens to execute the script and closes immediately once the script is finished.
    • non-interactive login shell: This is extremely rare, and you’re unlikey to encounter it. One way of launching one is echo command | ssh server. When ssh is launched without a command (so ssh instead of ssh command which will run command on the remote shell) it starts a login shell. If the stdin of the ssh is not a tty, it starts a non-interactive shell. This is why echo command | ssh server will launch a non-interactive login shell. You can also start one with bash -l -c command.

    If you want to play around with this, you can test for the various types of shell as follows:

    • Is this shell interactive?Check the contents of the $- variable. For interactive shells, it will include i:
      ## Normal shell, just running a command in a terminal: interacive
      $ echo $-
      ## Non interactive shell
      $ bash -c 'echo $-'
    • Is this a login shell?There is no portable way of checking this but, for bash, you can check if the login_shell option is set:
      ## Normal shell, just running a command in a terminal: interacive
      $ shopt login_shell 
      login_shell     off
      ## Login shell; 
      $ ssh localhost
      $ shopt login_shell 
      login_shell     on

    Putting all this together, here’s one of each possible type of shell:

    ## Interactive, non-login shell. Regular terminal
    $ echo $-; shopt login_shell
    login_shell     off
    ## Interactive login shell
    $ bash -l
    $ echo $-; shopt login_shell
    login_shell     on
    ## Non-interactive, non-login shell
    $ bash -c 'echo $-; shopt login_shell'
    login_shell     off
    ## Non-interactive login shell
    $ echo 'echo $-; shopt login_shell' | ssh localhost
    Pseudo-terminal will not be allocated because stdin is not a terminal.
    login_shell     on
  • [Wayback] Difference between Login Shell and Non-Login Shell? – Unix & Linux Stack Exchange

    A login shell is the first process that executes under your user ID when you log in for an interactive session. The login process tells the shell to behave as a login shell with a convention: passing argument 0, which is normally the name of the shell executable, with a - character prepended (e.g. -bash whereas it would normally be bash. Login shells typically read a file that does things like setting environment variables: /etc/profile and ~/.profile for the traditional Bourne shell, ~/.bash_profile additionally for bash/etc/zprofile and ~/.zprofile for zsh/etc/csh.login and ~/.login for csh, etc.

    When you log in on a text console, or through SSH, or with su -, you get an interactive login shell. When you log in in graphical mode (on an X display manager), you don’t get a login shell, instead you get a session manager or a window manager.

    It’s rare to run a non-interactive login shell, but some X settings do that when you log in with a display manager, so as to arrange to read the profile files. Other settings (this depends on the distribution and on the display manager) read /etc/profile and ~/.profile explicitly, or don’t read them. Another way to get a non-interactive login shell is to log in remotely with a command passed through standard input which is not a terminal, e.g. ssh <my-script-which-is-stored-locally (as opposed to ssh my-script-which-is-on-the-remote-machine, which runs a non-interactive, non-login shell).

    When you start a shell in a terminal in an existing session (screen, X terminal, Emacs terminal buffer, a shell inside another, etc.), you get an interactive, non-login shell. That shell might read a shell configuration file (~/.bashrc for bash invoked as bash/etc/zshrc and ~/.zshrc for zsh, /etc/csh.cshrc and ~/.cshrc for csh, the file indicated by the ENV variable for POSIX/XSI-compliant shells such as dash, ksh, and bash when invoked as sh$ENV if set and ~/.mkshrc for mksh, etc.).

    When a shell runs a script or a command passed on its command line, it’s a non-interactive, non-login shell. Such shells run all the time: it’s very common that when a program calls another program, it really runs a tiny script in a shell to invoke that other program. Some shells read a startup file in this case (bash runs the file indicated by the BASH_ENV variable, zsh runs /etc/zshenv and ~/.zshenv), but this is risky: the shell can be invoked in all sorts of contexts, and there’s hardly anything you can do that might not break something.

     I’m simplifying a little, see the manual for the gory details.

If you want to avoid the [[...]] bashishm, then read [Wayback] Bashism: How to make bash scripts work in dash – Greg’s Wiki.


Posted in *nix, *nix-tools, ash/dash, bash, bash, Communications Development, Conference Topics, Conferences, Development, Event, Internet protocol suite, Power User, Scripting, SFTP, Software Development, SSH, TCP | Leave a Comment »

%d bloggers like this: