-
Notifications
You must be signed in to change notification settings - Fork 3
Discussion: variable name reuse #15
Description
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.