Skip to content
This repository was archived by the owner on Mar 20, 2023. It is now read-only.
This repository was archived by the owner on Mar 20, 2023. It is now read-only.

Discussion: variable name reuse #15

@Mikulas

Description

@Mikulas

There are downsides to reusing variables:

# get deploy
$1 deploy-albkjl
$2 deploy-lnqww
$3 deploy-qweln
# get pods
$1 pod-1kl23
$2 pod-pcoiv
# delete deploy $2

This fails, $2 was replaced from deploy-lnqww with pod-pcoiv.

Also there is the unfortunate inconsistency with $3 still being set to deploy-qweln, so the last delete deploy $3 would not fail.

This is quite often an issue when reusing a command from history.

There are multiple possible fixes, each with some downsides:

a/ Unique variables for each command

# get pods
$1 pod-1kl23
$2 pod-pcoiv
# get pods
$3 pod-1kl23
$4 pod-pcoiv
  • Simple implementation.
  • Behaviour obvious to users.
  • Long living sessions will have high variables names, reducing usability. This can be bypassed by recycling variable names (eg wrapping at a 1000). There are multiple downsides to this, the main one being it does not properly resolve the history issue.

b/ Unique variables for each value

# get pods
$1 pod-1kl23
$2 pod-pcoiv
# get pods
$1 pod-1kl23
$3 pod-basdf
$2 pod-pcoiv
  • Simple implementation
  • Behaviour somewhat obvious to users. May be confusing why variables are not ordered (eg when a new pod is created as in the example above, or a pod is removed, …).
  • Ends with variable bloat, same as a/, but increases at the speed of kubernetes object lifecycle. a/ increases with each command.

c/ Reimplement history (rlwrap)

Keep the variables as they are now, but instead of saving the original command such as get pod $1) save the expanded version (get pod pod-1kl23). This does not however resolve the complete problem with variables being overridden. It does simplify non-containerized distribution. It may make sense to implement this in addition to other fixes.

There surely are other viable solutions which I cannot think of currently.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions