automotivemastermind / prompt Goto Github PK

Starship is a fantastic and highly customisable prompt that can (and likely should) replace the script-based prompt we include. Most of the functionality of prompt remains; this would only impact the look and feel.

The update-sln script in the default shell (sh) script location is not posix compliant. It relies on arrays, which are not available in posix-compliant shells like dash.

I tried to run this on a shared hosting server:

-jailshell-4.1$ ./install 
/home/user/.ssh/bashrc: line 42: bind: warning: line editing not enabled
/home/user/.ssh/bashrc: line 43: bind: warning: line editing not enabled
/home/user/.ssh/bashrc: line 44: bind: warning: line editing not enabled
Cannot make directory '/var/run/screen/S-user': Read-only file system

When attempting to run this command:
curl -fsSL https://git.io/am-prompt | sh -s -- --version v7.0.0 bash

it returns this error:
sh: line 90: pushd: prompt-master: No such file or directory

This also happens when replacing v7.0.0 with other versions such as v6.3.1

The default shell in the prompt 7.0 is bash when not specified. If you install prompt 7.0 with zsh and then force an update-prompt run by removing the sha tracking file, you will be switched back to bash.

# switches to bash from zsh
rm -rf ~/.am/prompt/.sha
update-prompt

# keeps zsh
rm -rf ~/.am/prompt/.sha
update-prompt zsh

What should happen when the shell is not specified:

1. if the user is currently using bash as the default shell, keep bash
2. if the user is currently using zsh as the default shell, keep zsh
3. if the user is using any shell other than bash or zsh, default to bash

Waffle IO is now defunct. I would like to evaluate alternatives with good support for notifications to both Slack and Microsoft Teams (the two primary communication tools used by our core contributors).

Any ideas on what we want/need here?

• migrate semantic versioning to semantic-release
• migrate docker build and test for macOS
• migrate docker build and test for ubuntu
• migrate docker build and test for fedora-29
• migrate docker build and test for fedora-30
• migrate docker build and test for fedora-31
• migrate docker build and test for mint
• migrate docker build and test for centos
• migrate docker build and test for debian

seems like there is an issue with the bootstrap.sh -> install.sh variable passing.

here are two sample files that cause the issue:
bootstrap.sh

#!/usr/bin/env sh

set -e

DIR=$(mktemp -d)
. "./test.sh" something "$DIR"

install.sh

SCRIPT_DIR=${2:-$(CDPATH= cd -- "$(dirname -- "$0")" && pwd -P)}

echo $SCRIPT_DIR

calling sh -x ./bootstrap.sh produces:

scott@DESKTOP-AFL3UD5:~$ sh -x ./bootstrap.sh
+ set -e
+ mktemp -d
+ DIR=/tmp/tmp.od69gATykC
+ . ./install.sh something /tmp/tmp.od69gATykC
+ dirname -- ./bootstrap.sh
+ CDPATH= cd -- .
+ pwd -P
+ SCRIPT_DIR=/home/scott
+ echo /home/scott

adding the . in front of the calling command to ./install.sh seems to cause something funky to happen and the second variable does not propagate .

removing the . in . "./test.sh" something "$DIR" to "./test.sh" something "$DIR" results in the correct output:

scott@DESKTOP-AFL3UD5:~$ sh -x ./bootstrap.sh
+ set -e
+ mktemp -d
+ DIR=/tmp/tmp.7Sbl0QtwLL
+ ./install.sh something /tmp/tmp.7Sbl0QtwLL
/tmp/tmp.7Sbl0QtwLL

PR incoming; want to see if this is the same case in other dists. also wondering why this was not caught in CI

When executing open-url from a non-tty, we should print the url instead of attempting to open

after upgrading prompt to 8.3.0-next.3 you can see the issues in the screen shot below

The list-directory shortcuts ("ll", "la", etc.) can not be accessed on macOS Sierra.

System version - macOS 10.12.6
Kernel version - Darwin 16.7.0
Bash version - GNU bash, version 4.4.19(1)-release (x86_64-apple-darwin16.7.0)
Prompt version - 4.0.5 (79b5025)

This will let people see what it looks like before they decide to try it out.

When auto-update is enabled, prompt currently checks for new versions on every execution of the profile, which includes every terminal window / tab that is opened. This has a side effect of significantly slowing down profile execution performance as well as being somewhat abusive of the GitHub api, which is what we use to check for new versions.

To avoid these drawbacks in 8.0, we disabled the auto update feature by default, but this will only effect net-new installations of prompt.

A better approach would be to perform a check once per day, or even once per week.

This could be done by writing a timestamp into the SHA marker file and evaluate (on every profile execution) whether or not that timestamp is more than a day or week old and only then checking for updates.

As part of doing this, we should disable the existing env var and replace it with a string based var containing one of the following values:

• never
• daily
• weekly

What does the community think of this idea? Any better alternatives?

After updating prompt I am back to ==> while originally it was ~ :-)

The latest update to posh-git-sh which is used by prompt to enable the two-line git prompt has introduced an issue with zsh.

Upstream issue:

lyze/posh-git-sh#48

Any update / reinstall of prompt will get the latest implementation of git-prompt.sh script from the above repository. Pending on the outcome of the upstream issue, we may want to revert to pulling an earlier version of git-prompt.sh for now.

Right now the uber install script does the following:

1. backs up ~/.ssh
2. removes ~/.ssh
3. installs uber to ~/.ssh

If other items (such as authorized_hosts or rsa_id) are present, they will be removed and must manually be restored from the backup.

We should leave any user files intact, or restore them automatically.

https://circleci.com/gh/automotiveMastermind/prompt/375

circleci output:

#!/bin/bash -eo pipefail
./publish.sh
/bin/bash: ./publish.sh: Permission denied

Exited with code exit status 126

After upgrading the shell can not find open-url to show the change-log.
After running exec -l $SHELL everything works again.

macOS 10.15.2

When running the "dotnet-install" command, I get the error "dotnet_install: Error: Unknown argument __channel". The issue can be worked around by manually modifying the dotnet-install.sh file and replacing "__channel" (two underscores) with "--channel" (two hyphens).

The issue appears to affect the "version" argument as well.

I was helping @zihli get set-up with prompt on macOS and ran into an issue installing the gcloud sdk using install-gcloud in version 8.3.0-next.4. I was able to recreate the error on a fresh install of macOS:

For reference the issue initially appeared on macOS 10.15 and then was reproduced on macOS 11. Existing prompt installs don't seem to have issues using the SDK if it was previously installed.

It looks like #85 made changes to the install script, and based on the error it looks like there's an issue with the C flag in tar -xfC.

Looking at the manpage for tar, it seems like -C and --directory are the same flag. I can't tell if that was intentional or not.

-C, --directory=DIR
    Change to DIR before performing any operations.
    This option is order-sensitive, i.e. it affects all options that follow.

Though the macOS manpage shows this:

-C directory, --cd directory, --directory directory
    In c and r mode, this changes the directory before adding the following files. 
    In x mode, change directories after opening the archive but before extracting entries from the archive.

I've tried changing the flags and reordering some of the options when calling tar and managed to get it to extract and start the install but the SDK isn't available on the path. While looking into that, I noticed there are inconstancies in the paths we're referencing the install at:

On line 47 in install-gcloud we're extracting compressed files to "$AM_PROMPT_USER"/gcloud but then on line 54 we're trying to run the install script from "$AM_PROMPT_USER"/bin/gcloud/install.sh.

In the bash version of set-gcloud-path we're checking "$AM_PROMPT_USER"/bin/gcloud/gcloud but in the zsh version of that script we're checking "$HOME/.gcloud/bin/gcloud".

See: lyze/posh-git-sh#15

The macOS ssh-agent does not support security key algorithms (ed25519-sk and ecdsa-sk) out of the box. We currently support yubikeys by configuring the PGP module within the ssh-agent, but this requires the use of the aging rsa algorithm.

We have a few options:

1. keep it the way it is for now and hope that macOS adds future support for sk algos
2. We could support yubikeys via fido by disabling the default ssh-agent and replacing it with OpenSSH > 8.2, which has native support for sk algos -- this would bring macOS in line with our linux counterparts

I'd like to know what others think. Is anyone else using security keys besides me?

After updating to prompt 8.0 I was getting the following when opening a new prompt:

prompt: using zsh shell
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent NOP': General error
prompt: latest version already installed: be80c613ad66508acbc9061dd40bbbf3cac5ea8b.
patrick@VM : ~

Running gpg and gpgconf seems to have resolved the issue. But it's a pretty bad first run/upgrade experience for users who have't used gpg before.

System Information:

• Prompt 8.0.0
• Windows 10 running Ubuntu 2004.2020.812.0 via WSL1

HI, I am getting the following error when I try to install:

user@machine : ~/src/GitHub/uber
 [master] ==> ./install 
-bash(19335,0x7fff75675000) malloc: *** error for object 0x7f9162507490: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

so I did:

user@machine : ~
 ==> mv .ssh .ssh.old

user@machine : ~
 ==> cd src/GitHub/uber/

user@ machine : ~/src/GitHub/uber
 [master] ==> ./install 
cp: /Users/user/.ssh/*: No such file or directory

This created a new .ssh directory for me. I ended up removing the new .ssh directory and renaming my .ssh.old back to .ssh.

I then went into the .ssh directory and removed all of the traces of the old version of uber, closed the terminal window, opened a new terminal window and then ran the install again. That worked.

The gcloud-install assumes bash and sources bash completion scripts in all shells

Hi @dmccaffery - @patrickserrano sent me here after I mentioned that I ran into this issue on my machine after running update-prompt today. The difference was that this wasn't in WSL1, it was in the terminal on my mac (Catalina, macOS 10.15.6).

prompt: using bash shell
gpgconf: error running '/usr/local/Cellar/gnupg/2.2.26/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/local/Cellar/gnupg/2.2.26/bin/gpg-connect-agent NOP': General error
prompt: a new version of prompt is available: a95f87e6bdba2404804fb3ba30396805c1b41102
  - run the update-prompt command line tool to upgrade

Originally posted by @jeffreypmoran in #69 (comment)

After updating prompt the follow error occurs when running the command: gcloud

It appears this issue is only resolved be reinstalling python 2 with:
brew reinstall python@2

Traceback (most recent call last):
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 147, in <module>
  globals()[__func_name] = __get_hash(__func_name)
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 97, in __get_builtin_constructor
  raise ValueError(‘unsupported hash type ’ + name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 147, in <module>
  globals()[__func_name] = __get_hash(__func_name)
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 97, in __get_builtin_constructor
  raise ValueError(‘unsupported hash type ’ + name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 147, in <module>
  globals()[__func_name] = __get_hash(__func_name)
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 97, in __get_builtin_constructor
  raise ValueError(‘unsupported hash type ’ + name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 147, in <module>
  globals()[__func_name] = __get_hash(__func_name)
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 97, in __get_builtin_constructor
  raise ValueError(‘unsupported hash type ’ + name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 147, in <module>
  globals()[__func_name] = __get_hash(__func_name)
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 97, in __get_builtin_constructor
  raise ValueError(‘unsupported hash type ’ + name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 147, in <module>
  globals()[__func_name] = __get_hash(__func_name)
 File “/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py”, line 97, in __get_builtin_constructor
  raise ValueError(‘unsupported hash type ’ + name)
ValueError: unsupported hash type sha512
ERROR: gcloud failed to load: ‘module’ object has no attribute ‘sha256’
  gcloud_main = _import_gcloud_main()
  import googlecloudsdk.gcloud_main
  from googlecloudsdk.api_lib.iamcredentials import util as iamcred_util
  from googlecloudsdk.api_lib.util import apis_internal
  from googlecloudsdk.core import properties
  from googlecloudsdk.core import config
  from googlecloudsdk.core.util import files as file_utils
  class Checksum(object):
  def __init__(self, algorithm=hashlib.sha256):
This usually indicates corruption in your gcloud installation or problems with your Python interpreter.
Please verify that the following is the path to a working Python 2.7 executable:
  /usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
If it is not, please set the CLOUDSDK_PYTHON environment variable to point to a working Python 2.7 executable.
If you are still experiencing problems, please reinstall the Cloud SDK using the instructions here:
  https://cloud.google.com/sdk/```

If someone copies the entire command (including the comment containing the expected shell path), then an error will be reported.

We should remove (or move) the path as its unclear whether or not that should be copied.

I've been getting the same error locally on macOS:

Originally posted by @patrickserrano in #51 (comment)

After updating my prompt I get the folowing output when my terminal starts ->

Last login: Thu Jan 14 12:47:40 on console

prompt: using bash shell
prompt: a new version of prompt is available: a95f87e6bdba2404804fb3ba30396805c1b41102
 - run the update-prompt command line tool to upgrade
-bash: /Users/<USERNAME>/.am/prompt/bash/completions/*: No such file or directory
-bash: __posh_git_ps1: command not found

The -bash: __posh_git_ps1: command not found appears after running any command in prompt.
I also receive a prompt: cannot retrieve SHA of latest version. Are you connected to the internet? quite a bit even though I am connected to the internet.

macOS Catalina Version 10.15.7

The autoupdate for prompt does not currently fail gracefully when disconnected from the network

There are a few typos in the readme.

We should also update the readme to follow our default guidelines at aM.

• screenshot of how the prompt looks (suggestion from #9)
• table for project info
• table for major credits
• install instructions
• list of features
  • git prompt
  • user variables
  • bookmarking
  • user bashrc
• list of available commands
  • all platforms
  • Darwin (macOS)
• reference CREDITS

Let's figure out how we want to implement docs. There is enough going on that a README isn't enough to contain everything and I think it makes sense to build out some better docs, but how to do it?

Couple of options:

1. Hugo (or similar) with GitHub Pages
2. GitHub Wiki

Prompt is simple and composable enough that it should be possible to document everything in the wiki with enough organisation for folks to find what they need.

I think GitHub Pages is a better alternative if we want to seamlessly integrate prompt docs with docs from any other repos in the org. It's also better if you want to force docs as part of the code; requiring it for PRs.

This decision should not come from me, but I did want to add it as an issue so it's tracked (topic keeps coming up).

Both Monokai and dark-mode themes fail to launch in terminal

macOS 10.15.2

installing homebrew...
Password:
Homebrew is not (yet) supported on ARM processors!
Rerun the Homebrew installer under Rosetta 2.
If you really know what you are doing and are prepared for a very broken experience you can use another installation option for installing on ARM:
  https://docs.brew.sh/Installation

We should override the installation of homebrew with the following:

1. install rosetta 2 if not already installed
2. install homebrew via rosetta 2
3. install arm-based brew into /opt/homebrew as described here: https://docs.brew.sh/Installation#untar-anywhere
4. add alias for brew-arm pointing to /opt/homebrew/bin/brew that includes the arch env-var
5. print out a warning that not everything installed via brew-arm will necessarily work; it will largely depend on what is installed

Add tests for the following *nix distributions:

• Ubuntu
• Fedora
• Debian
• CentOS
• Mint
• macOS