Skip to content

Latest commit

 

History

History
63 lines (39 loc) · 3.32 KB

TODO.md

File metadata and controls

63 lines (39 loc) · 3.32 KB
Raw

Figure out how to automatically update ttab.rb for Homebrew on every new release

URL and sha256 hash must be updated for every release.

Manual instructions for now:

  • Commit the tagged release in order to make GitHub generate the new version's *.tar.gz package.

  • Update the *.rb file in terms of initially just the URL; e.g., for 0.7.2:

    • url "https://github.com/mklement0/ttab/archive/v0.9.0.tar.gz"

  • Use the formula locally, which predictably fails due to the outdated hash, but the error message will report the new hash:

HOMEBREW_NO_AUTO_UPDATE=1 brew install --formula ./ttab.rb

OR

$env:HOMEBREW_NO_AUTO_UPDATE=1; brew install --formula ./ttab.rb

  • Copy the new hash from the error message and update the *.rb file again, with the new hash.

  • Run the formual locally again, as above, which should now succeed.

    • Verify that rreadlink "$(which ttab)" shows that /usr/local/bin/ttab links to the correct version.

  • Commit and push.

NOTE: Since ttab is only available via a custom Homebrew tap, there is NO need to submit a PR to the Homebrew repo (unlike for fileicon). However, brew upgrade mklement0/ttab/ttab must be run to get the latest version based on the repo's .rb file. ?? TBD: Does this need a general brew update first, or does the above do that implicitly?

Consider supporting PowerShell

Note: The problems relate to specifying a startup command for the new tab:

  • On macOS, even if no user-specified startup command is given, an automatically constructed one is used for technical reasons, namely to ensure preserving the caller's working directory.

  • On Linux, only user-specified startup commands are affected, because gnome-terminal automatically preserves the caller's working dir.

Specific startup command problems:

  • gnome-terminal (Linux):

    • The \-escaping of spaces and POSIX shell metacharacters performed by ttab makes even explicit calls to the PowerShell CLI (e.g., ttab --print-script exec pwsh -noexit -c 'get-date; ls').
    • Short of using pwsh -EncodedCommand <base64-encoded-command>, which is obviously impractical, there is currently no workaround.

  • Terminal / iTerm (macOS):

    • BUG: The AppleScript commands that are supposed to submit startup commands are only pasted on the new tab's command line, not also submitted, due to a bug as of PowerShell Core 7.1.0-preview.7 in combination with PSReadLine as of 2.0.4 - doesn't happen if PSReadLine isn't loaded. !! THE PROBLEM DOES NOT OCCUR in PowerShell Core 7.0.3, neither with the in-box PSReadLine 2.0.2 nor with PSReadLine 2.0.4 !!

    • CONCEPTUAL PROBLEM: Passing a single argument that isn't an executable (alone), which includes argument-less PowerShell cmdlet calls, is currently pasted and submitted via AppleScript as an eval call with a POSIX-shell-metacharacters-escaped-with-\ string, neither of which PowerShell understands. Executable calls with individual arguments that require quoting (e.g., ttab Get-ChildItem '/Library/Application Support') break due to the \-escaping. The challenge is that we have no (easy) way of knowing what shell the target profile (settings) is configured to use.

    • Short of using pwsh -EncodedCommand <base64-encoded-command>, which is obviously impractical, there is currently no workaround.