Skip to content
This repository has been archived by the owner on Apr 24, 2020. It is now read-only.

Multiple-IP's on a single interface, prompt silently fails #823

Closed
Jekotia opened this issue May 4, 2018 · 4 comments
Closed

Multiple-IP's on a single interface, prompt silently fails #823

Jekotia opened this issue May 4, 2018 · 4 comments
Labels

Comments

@Jekotia
Copy link

Jekotia commented May 4, 2018

I know this SHOULD be a pull request, but I don't know nearly enough about the implications to be comfortable with that. In my use case, a CentOS 7 server with different IP addresses on eth0 and eth0:0, the existing method for saving the system IP to the $ip variable records two IP's, one per line. This multi-line $ip variable causes any prompt it's used in to silently fail to load.

Inserted as line 929, the following will set $ip to equal ONLY the first line.
ip=$(sed -n 1p <<< "$ip")

@dritter
Copy link
Member

dritter commented May 11, 2018

Did you specify your interface via POWERLEVEL9K_IP_INTERFACE? If not, could you try that?
And could you post the raw output of ip link ls up | grep -o -E ":\s+[a-z0-9]+:" | grep -v "lo" | grep -o "[a-z0-9]*" (if this does not contain sensitive data). That would be helpful.

@bhilburn
Copy link
Member

bhilburn commented Oct 8, 2018

@Jekotia - Just checking in on this, per @dritter's guidance?

@bhilburn
Copy link
Member

bhilburn commented Nov 7, 2018

Closing due to inactivity. Feel free to re-open if needed!

@bhilburn bhilburn closed this as completed Nov 7, 2018
Jekotia added a commit to Jekotia/powerlevel9k that referenced this issue Aug 27, 2019
Due to issues matching with some versions of iproute's 'ip' command, I've rewritten and thoroughly commented. See Powerlevel9k#823

If desired, a lot of this can be rewritten to be shorter (and theoretically a smidge faster to execute); I chose to write the initial code in this manner to make it easier to read what I've done when judging the pull request.
@Jekotia
Copy link
Author

Jekotia commented Aug 27, 2019

I'm terribly sorry for the delay.

I dug back into this today, and was able to determine that there are instances where IP address 'acquisition' by powerlevel9k will silently fail due to an old version of the ip program which does not support the -brief argument. I fixed this in my instances by updating that program, so I do not have any light to shed on an alternative method.

However, it does not work at all in my WSL 2.0 Debian environment. I've determined what I believe to be the root cause, using the following excerpt of the 'parseIp` function (I can confidently say that this silently failing is the cause) as a standalone script:

function p9k::parseIp() {
    local desiredInterface="${1}"

    if [[ -z "${desiredInterface}" ]]; then
        desiredInterface="^[^ ]+"
    fi

    local ROOT_PREFIX="${2}"
    if [[ "$OS" == "OSX" ]]; then
        echo #REMOVED DUE TO IRREVALENCY TO THIS ISSUE
    else
        local -a interfaces
        interfaces=( "${(f)$(${ROOT_PREFIX}/sbin/ip -brief -4 a show 2>/dev/null)}" )
        local pattern="^${desiredInterface}[ ]+UP[ ]+([^/ ]+)"
        for interface in "${(@)interfaces}"; do
        if [[ "$interface" =~ $pattern ]]; then
            echo "${match[1]}"
            return 0
        fi
        done
    fi

    return 1
}

p9k::parseIp "eth6" ""

This is identical to the official function, except for where I removed the MacOSX lines (in order to make it easier to focus on the actual code in question, without compromising the accuracy of the testing).

In the terminal, the raw output of the command saved into interfaces is messy and sort of useless, so I modified the command in order to check what output is being passed along for parsing:

$    /sbin/ip -brief -4 a show
eth0             192.168.26.1/24
eth1             192.168.68.1/24
eth2             169.254.224.144/16
eth3             169.254.188.143/16
eth4             192.168.56.1/24
eth5             192.168.66.17/28
eth6             172.16.205.1/24
eth7             169.254.129.230/16
eth8             192.168.99.1/24
lo               127.0.0.1/8
wifi0            169.254.126.57/16
wifi1            169.254.49.176/16
wifi2            169.254.215.207/16

This lacks the UP that $pattern is searching for. This results in a failure to match a $desiredInterface declared with POWERLEVEL9K_IP_INTERFACE.

I've created a pull request that will address this, which you can find here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants