* Two different zsh sessions handle $* differently
@ 2017-08-22 17:22 Mikael Puhakka
2017-08-22 18:40 ` Eitan Adler
2017-08-23 19:17 ` Phil Pennock
0 siblings, 2 replies; 9+ messages in thread
From: Mikael Puhakka @ 2017-08-22 17:22 UTC (permalink / raw)
To: zsh-workers
Hi zsh-workers,
Recently I noticed that my journal script has started to lose data. Then
I noticed that this is somehow in how zsh handles my little helper
function. This peculiarly affects one zsh session and not many others
that I can see.
This is what happens in a freshly launched session:
(~) echo $ZSH_VERSION
5.2
(~) whence -f j
j () {
noglob journal.py "$*"
}
(~) j Test. ABC this is a test.
argv ['/home/progo/pika/journal.py', 'Test. ABC this is a test.']
And this is what the faulty session does:
(~) echo $ZSH_VERSION
5.2
(~) whence -f j
j () {
noglob journal.py "$*"
}
(~) j Test. ABC this is a test.
argv ['/home/progo/pika/journal.py', 'Test.']
The python script is modified to be trivial:
(~) head -n5 /home/progo/pika/journal.py
#!/usr/bin/env python3
import sys
print ('argv', sys.argv)
sys.exit (0)
The faulty session might be a longer running one, if there's a way to
find out zsh-uptime, let me know. But I have several terminals open with
at least as old zsh sessions running, they behave correctly.
Unless X crashes or there's a long electricity break, I'll have these
sessions open if anyone comes up with something I can run to help with
this issue.
BR,
-- Mikael
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-22 17:22 Two different zsh sessions handle $* differently Mikael Puhakka
@ 2017-08-22 18:40 ` Eitan Adler
2017-08-22 19:04 ` Daniel Shahaf
2017-08-22 19:04 ` Mikael Puhakka
2017-08-23 19:17 ` Phil Pennock
1 sibling, 2 replies; 9+ messages in thread
From: Eitan Adler @ 2017-08-22 18:40 UTC (permalink / raw)
To: Mikael Puhakka; +Cc: Zsh hackers list
On 22 August 2017 at 13:22, Mikael Puhakka <mr.progo@gmail.com> wrote:
> Hi zsh-workers,
>
> Recently I noticed that my journal script has started to lose data. Then
> I noticed that this is somehow in how zsh handles my little helper
> function. This peculiarly affects one zsh session and not many others
> that I can see.
for key val in ${(kv)options}; do echo "$key -> $val"; done
in each shell please
--
Eitan Adler
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-22 18:40 ` Eitan Adler
@ 2017-08-22 19:04 ` Daniel Shahaf
2017-08-22 19:19 ` Eitan Adler
2017-08-22 19:04 ` Mikael Puhakka
1 sibling, 1 reply; 9+ messages in thread
From: Daniel Shahaf @ 2017-08-22 19:04 UTC (permalink / raw)
To: zsh-workers; +Cc: Mikael Puhakka
Eitan Adler wrote on Tue, 22 Aug 2017 14:40 -0400:
> for key val in ${(kv)options}; do echo "$key -> $val"; done
> in each shell please
For future reference, just 'set -o' does the same with less typing.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-22 18:40 ` Eitan Adler
2017-08-22 19:04 ` Daniel Shahaf
@ 2017-08-22 19:04 ` Mikael Puhakka
1 sibling, 0 replies; 9+ messages in thread
From: Mikael Puhakka @ 2017-08-22 19:04 UTC (permalink / raw)
To: Eitan Adler; +Cc: Zsh hackers list
They are the same in both:
posixargzero -> off
autolist -> on
printexitvalue -> off
kshzerosubscript -> off
histreduceblanks -> off
chaselinks -> off
extendedglob -> off
localloops -> off
histnostore -> off
automenu -> on
globcomplete -> off
unset -> on
listpacked -> off
promptsubst -> on
shwordsplit -> off
pathdirs -> off
kshtypeset -> off
listtypes -> on
warncreateglobal -> off
promptbang -> off
dotglob -> off
braceexpand -> on
listbeep -> on
correctall -> off
privileged -> off
numericglobsort -> off
histverify -> off
trackall -> on
histsubstpattern -> off
globstarshort -> off
cbases -> off
rcquotes -> off
posixaliases -> off
histfindnodups -> on
bashautolist -> off
sharehistory -> off
overstrike -> off
kshautoload -> off
incappendhistory -> on
appendcreate -> off
promptcr -> on
mailwarn -> off
pushdignoredups -> off
interactive -> on
ignoreeof -> off
globsubst -> off
rematchpcre -> off
monitor -> on
histsavebycopy -> on
histbeep -> on
debugbeforecmd -> on
magicequalsubst -> off
rmstarsilent -> off
posixjobs -> off
hashcmds -> on
posixtraps -> off
extendedhistory -> off
notify -> on
kshoptionprint -> off
histexpiredupsfirst -> off
glob -> on
posixcd -> off
braceccl -> off
badpattern -> on
longlistjobs -> off
banghist -> on
dvorak -> off
alwaystoend -> off
hashall -> on
globalexport -> on
ksharrays -> off
correct -> off
autonamedirs -> off
histexpand -> on
typesetsilent -> off
rmstarwait -> off
histnofunctions -> off
autoparamslash -> on
trapsasync -> off
sunkeyboardhack -> off
promptsp -> on
histsavenodups -> off
autocd -> off
allexport -> off
posixidentifiers -> off
cshjunkiehistory -> off
autopushd -> off
completeinword -> off
completealiases -> off
aliases -> on
autocontinue -> off
appendhistory -> on
singlelinezle -> off
hashlistall -> on
ignoreclosebraces -> off
recexact -> off
localoptions -> off
interactivecomments -> off
errexit -> off
cshjunkiequotes -> off
markdirs -> off
hashdirs -> on
cdablevars -> off
rcexpandparam -> off
vi -> off
printeightbit -> off
multifuncdef -> on
xtrace -> off
login -> off
cshjunkieloops -> off
histappend -> on
histignorespace -> off
evallineno -> on
shfileexpansion -> off
rcs -> on
functionargzero -> on
errreturn -> off
combiningchars -> off
histignoredups -> on
histfcntllock -> off
beep -> on
autoremoveslash -> on
hup -> on
globdots -> off
autoparamkeys -> on
shnullcmd -> off
multibyte -> on
zle -> on
promptpercent -> on
flowcontrol -> on
continueonerror -> off
incappendhistorytime -> off
autoresume -> off
globassign -> off
caseglob -> on
shortloops -> on
bsdecho -> off
cprecedences -> off
log -> on
transientrprompt -> off
verbose -> off
localpatterns -> off
ignorebraces -> off
pipefail -> off
equals -> on
menucomplete -> off
cshnullglob -> off
casematch -> on
promptvars -> on
histallowclobber -> off
bareglobqual -> on
shinstdin -> on
restricted -> off
pushdminus -> off
nullglob -> off
chasedots -> off
mailwarning -> off
listambiguous -> on
cshnullcmd -> off
bashrematch -> off
octalzeroes -> off
forcefloat -> off
exec -> on
multios -> on
emacs -> off
nomatch -> on
pathscript -> off
localtraps -> off
stdin -> on
onecmd -> off
kshglob -> off
clobber -> on
posixbuiltins -> off
alwayslastprompt -> on
pushdtohome -> off
histignorealldups -> off
hashexecutablesonly -> off
pushdsilent -> off
shoptionletters -> off
physical -> off
sourcetrace -> off
histlexwords -> off
bgnice -> on
globalrcs -> on
posixstrings -> off
checkjobs -> on
shglob -> off
singlecommand -> off
listrowsfirst -> off
BR,
-- Mikael
On 8/22/17, Eitan Adler <lists@eitanadler.com> wrote:
> On 22 August 2017 at 13:22, Mikael Puhakka <mr.progo@gmail.com> wrote:
>> Hi zsh-workers,
>>
>> Recently I noticed that my journal script has started to lose data. Then
>> I noticed that this is somehow in how zsh handles my little helper
>> function. This peculiarly affects one zsh session and not many others
>> that I can see.
>
> for key val in ${(kv)options}; do echo "$key -> $val"; done
> in each shell please
>
>
> --
> Eitan Adler
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-22 19:04 ` Daniel Shahaf
@ 2017-08-22 19:19 ` Eitan Adler
0 siblings, 0 replies; 9+ messages in thread
From: Eitan Adler @ 2017-08-22 19:19 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: Zsh hackers list, Mikael Puhakka
On 22 August 2017 at 15:04, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Eitan Adler wrote on Tue, 22 Aug 2017 14:40 -0400:
>> for key val in ${(kv)options}; do echo "$key -> $val"; done
>> in each shell please
>
> For future reference, just 'set -o' does the same with less typing.
Good to know - thanks! I knew about "setopt" and "unsetopt" but not "set -o" :)
--
Eitan Adler
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-22 17:22 Two different zsh sessions handle $* differently Mikael Puhakka
2017-08-22 18:40 ` Eitan Adler
@ 2017-08-23 19:17 ` Phil Pennock
2017-08-24 6:05 ` Mikael Puhakka
1 sibling, 1 reply; 9+ messages in thread
From: Phil Pennock @ 2017-08-23 19:17 UTC (permalink / raw)
To: Mikael Puhakka; +Cc: zsh-workers
On 2017-08-22 at 20:22 +0300, Mikael Puhakka wrote:
> (~) whence -f j
> j () {
> noglob journal.py "$*"
> }
This is broken. If you invoke >> j f* << then the argument list passed
to the function is already expanded. In this case, you want an alias
instead. Then you can either have `journal.py` do
' '.join(sys.argv[1:])
for you, or still use a function to join things and use an
alias/function combination. In your shoes, I'd have Python join the
parameters and _just_ use an alias.
Aliases happen before glob expansion and dispatch. Functions are
invoked after determining their parameter list, too late for `noglob`
inside the function to help.
# python script looks in all sys.argv[1:] :
alias j='command journal.py'
or:
# python script just looks at argv[1] :
function f_j { journal.py "$*"; }
alias j='noglob f_j'
> (~) head -n5 /home/progo/pika/journal.py
> #!/usr/bin/env python3
Which python3 is used? Is it the same one in both environments, or is
pyenv or equivalent using shell environment variables or .pyenv-version
files to dispatch to a different interpreter, with one having sys.argv
getting mangled in the start-up files?
Is os.environ[PYTHONSTARTUP] defined, causing logic to happen before
your code sees sys.argv?
Do you have any suffix or global aliases defined in the older zsh
instance? `alias -s`, `alias -g`?
% j() { print -l :${^*} }
% j Test. ABC this is a test.
:Test.
:ABC
:this
:is
:a
:test.
% alias -g ABC='#'
% j Test. ABC this is a test.
:Test.
%
You can use `setopt xtrace` (or `set -x`) to have zsh emit diagnostics
of what it's doing, so if you do that before invoking `j` then you might
see something different in the two environments.
-Phil
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-23 19:17 ` Phil Pennock
@ 2017-08-24 6:05 ` Mikael Puhakka
2017-08-24 8:48 ` Daniel Shahaf
0 siblings, 1 reply; 9+ messages in thread
From: Mikael Puhakka @ 2017-08-24 6:05 UTC (permalink / raw)
To: Phil Pennock; +Cc: zsh-workers
On 8/23/17, Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> This is broken. If you invoke >> j f* << then the argument list passed
> to the function is already expanded. In this case, you want an alias
> instead.
Thanks for pointing this out. I knew it didn't work as intended and I
was pondering why's that the case -- I had it as an alias originally
when things worked and then started to functionize things. Wasn't using
the alias much at the time so the regression went largely unnoticed.
> Which python3 is used? Is it the same one in both environments, or is
> pyenv or equivalent using shell environment variables or .pyenv-version
> files to dispatch to a different interpreter, with one having sys.argv
> getting mangled in the start-up files?
Both examples run on home directory, the env points to the same python3
version 3.4.5, no virtualenvs.
> Is os.environ[PYTHONSTARTUP] defined, causing logic to happen before
> your code sees sys.argv?
Nothing defined there.
> Do you have any suffix or global aliases defined in the older zsh
> instance? `alias -s`, `alias -g`?
No, nothing.
> You can use `setopt xtrace` (or `set -x`) to have zsh emit diagnostics
> of what it's doing, so if you do that before invoking `j` then you might
> see something different in the two environments.
This shows something alright:
(~) j Test. ABC ABC ABC.
+preexec:0> print -Pn '\e]2;zsh: %~\a'
+zsh:1165> j Test. ABC ABC ABC.
(*) +j:0> journal.py Test.ABCABCABC.
argv ['Test.']
+precmd:0> print -Pn '\e]2;zsh: %~\a'
+zsh:1166> parse_git_branch
+parse_git_branch:1> git branch --no-color
+parse_git_branch:2> sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
The starred line doesn't look correct. With a fresh session the same
line goes like this:
+j:0> journal.py 'Test. ABC ABC ABC.'
Now I'm not sure what happens. The faulty one strips whitespace and
concatenates, (there doesn't seem to be nulls or anything separating the
arguments) yet python sees only a part of the argument.
Hope this helps.
BR,
-- Mikael
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-24 6:05 ` Mikael Puhakka
@ 2017-08-24 8:48 ` Daniel Shahaf
2017-08-24 9:07 ` Mikael Puhakka
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Shahaf @ 2017-08-24 8:48 UTC (permalink / raw)
To: Mikael Puhakka; +Cc: zsh-workers, Phil Pennock
Mikael Puhakka wrote on Thu, 24 Aug 2017 09:05 +0300:
> On 8/23/17, Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> > You can use `setopt xtrace` (or `set -x`) to have zsh emit diagnostics
> > of what it's doing, so if you do that before invoking `j` then you might
> > see something different in the two environments.
>
> This shows something alright:
>
> (~) j Test. ABC ABC ABC.
> +preexec:0> print -Pn '\e]2;zsh: %~\a'
> +zsh:1165> j Test. ABC ABC ABC.
> (*) +j:0> journal.py Test.ABCABCABC.
> argv ['Test.']
> +precmd:0> print -Pn '\e]2;zsh: %~\a'
> +zsh:1166> parse_git_branch
> +parse_git_branch:1> git branch --no-color
> +parse_git_branch:2> sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
>
> The starred line doesn't look correct. With a fresh session the same
> line goes like this:
>
> +j:0> journal.py 'Test. ABC ABC ABC.'
>
> Now I'm not sure what happens. The faulty one strips whitespace and
> concatenates, (there doesn't seem to be nulls or anything separating the
> arguments) yet python sees only a part of the argument.
Have you set $IFS to $'\0'? Check with 'typeset -p IFS'.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Two different zsh sessions handle $* differently
2017-08-24 8:48 ` Daniel Shahaf
@ 2017-08-24 9:07 ` Mikael Puhakka
0 siblings, 0 replies; 9+ messages in thread
From: Mikael Puhakka @ 2017-08-24 9:07 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: zsh-workers, Phil Pennock
On 8/24/17, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Have you set $IFS to $'\0'? Check with 'typeset -p IFS'.
>
That's it!
(~) typeset -p IFS
typeset IFS='
'
vs. the faulty one:
(~) typeset -p IFS
typeset IFS=
Now, this might have happened accidentally at some point but there's no
history for it, sadly.
Big thanks to everyone!
BR,
-- Mikael
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-08-24 9:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-22 17:22 Two different zsh sessions handle $* differently Mikael Puhakka
2017-08-22 18:40 ` Eitan Adler
2017-08-22 19:04 ` Daniel Shahaf
2017-08-22 19:19 ` Eitan Adler
2017-08-22 19:04 ` Mikael Puhakka
2017-08-23 19:17 ` Phil Pennock
2017-08-24 6:05 ` Mikael Puhakka
2017-08-24 8:48 ` Daniel Shahaf
2017-08-24 9:07 ` Mikael Puhakka
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).