Re: gcc12 fault?
On 2/6/2023 16:47, Ken Cunningham wrote: You have probably already noted that which and type are both built in to the default zsh on Ventura and as far as I can tell from my testing here give identical results in every case. Both correctly predict the binary that will be executed in every case I tried. Indeed, zsh is a bit special and implements both 'which' and 'type' in terms of its 'whence' builtin (which has a lot of options and can tell you pretty much anything you would ever want to know about a command's disposition, check it out.) You will notice /usr/bin/which can thus give different results to just 'which'. What will happen when you add and remove binaries from an upstream PATH folder is a bit difficult to predict accurately. I won't try to summarize the findings only to have someone point out their idea of an exception, but it's fair to say that it's best to open a new shell to get predictable results. You would want to start a new shell if you changed the startup files. Otherwise 'hash -r' is quite sufficient. Changing the value of PATH at runtime will do that automatically in modern shells, BTW. - Josh
Re: gcc12 fault?
> On Jun 1, 2023, at 6:18 PM, Joshua Root wrote: > > Ken Cunningham wrote: > >> what you see is difficult to explain, unless the PATH changed between the >> two tests. >> >> if >> >> 'which gcc' gives /opt/local/bin/gcc >> >> then >> >> gcc --version >> >> should give exactly the same as >> >> /opt/local/bin/gcc --version > > Not necessarily. Shells cache command locations, so if 'gcc' was run prior to > the creation of /opt/local/bin/gcc, subsequently invocations will continue to > run the previously found gcc. Running 'hash -r' or starting a new shell will > give you an empty cache and thus set things right. > > The 'which' command doesn't know about the shell's cache state; it only looks > at the current PATH. This is why 'type' often helps to understand what's > going on in these situations, as Richard hinted. > > - Josh > You have probably already noted that which and type are both built in to the default zsh on Ventura and as far as I can tell from my testing here give identical results in every case. Both correctly predict the binary that will be executed in every case I tried. What will happen when you add and remove binaries from an upstream PATH folder is a bit difficult to predict accurately. I won't try to summarize the findings only to have someone point out their idea of an exception, but it's fair to say that it's best to open a new shell to get predictable results. K
vim update
Trying to update vim to the latest update that I saw today in macports.
Unfortunately it fails to patch:
Error: Failed to patch vim: command execution failed
Error: See
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/main.log
for details.
:info:patch Executing: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/work/vim-9.0.1499"
&& /usr/bin/patch -p0 <
'/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/editors/vim/files/patch-python3.diff'
:debug:patch system: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/work/vim-9.0.1499"
&& /usr/bin/patch -p0 <
'/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/editors/vim/files/patch-python3.diff'
:info:patch patching file 'src/configure.ac'
:info:patch 1 out of 1 hunks failed--saving rejects to
'src/configure.ac.rej'
:info:patch Command failed: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/work/vim-9.0.1499"
&& /usr/bin/patch -p0 <
'/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/editors/vim/files/patch-python3.diff'
:info:patch Exit code: 1
:error:patch Failed to patch vim: command execution failed
:debug:patch Error code: CHILDSTATUS 38437 1
:debug:patch Backtrace: command execution failed
:debug:patch while executing
:debug:patch "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:patch invoked from within
:debug:patch "command_exec patch "" "< '$patch'""
:debug:patch (procedure "portpatch::patch_main" line 41)
:debug:patch invoked from within
:debug:patch "$procedure $targetname"
:error:patch See
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/main.log
for details.
how to prepare an existing Macports instance for an xCode update or fix Macports after xCode update?
Hi; how to prepare an existing Macports instance for an xCode update or fix Macports after xCode update? I have an xCode update notification. I have an existing MacPorts installation. Do I need to do anything to the MacPorts installation prior to the xCode update? Do I need to do anything to the MacPorts installation after the cxCode update? I did not see any guidance in the MacPorts manual regarding these two questions. Thank you, Ken Wolcott
