Is it possible i can integrate this line of code to automate my work on my The Charlie Brown website. I need to check all the details.
The PyCmd project has moved to GitHub: https://github.com/horeah/PyCmd
Port to Python3
The changes for the Py3 port have now been merged into master and released with 20230107. Thanks @UFO for helping with this!
Port to Python3
Port to Python3
I'm of course fine with it, just like you suggested. Thanks
I'd still like to thank you: you did spend some time/effort on this, and pointed me to a nice starting point for me to work on. The whatsnew would say "thanks github.org/ufo for help" -- unless you object (or prefer an alternate credit such as name or email).
Hi Horea, thanks a lot, but no need to credit me! I've seen some other forks of your project on Github in the past and just gathered some Python 3 port patches from here and there. In the end I didn't have to add a lot (of quick and dirty hacks) to make it really work for me. Then I just created a branch to make it easier for you to diff, because the other forks on Github always added a lot of additional strange features, so it was kinda cumbersome to see the naked Python 3 port. I see you already...
The patch did not apply directly (I had some unpushed commits on my local branch -- my bad) so I sort of went through your changes and applied them manually, with some small adjustments here and there; you can see the result on branch "py3" in the SF repo. Among the adjustments I would note: 1. dropped support for Py2: I expect most users' init.py files are Py3-compatible, or at least can be ported trivially 2. simplified the console.py port 3. fixed the setting of the window title (via SetConsoleTitleA)...
Port to Python3
Mark last release in the whatsnew file
I had a quick look and this looks very nice (and quite helpful) -- thank you very much! I was actually planning to work on the Py3 porting during the next few days as I have some spare time; so your contribution comes at the perfect time :) I will review the diff and come back to you to discuss about integrating the changes.
Hi Horea, yes, you should really move your great project to Github. Regarding Python 3: I've pushed a branch today which is compatible with Python 2 and Python 3, since I've needed it to be compatible with both versions in a personal project. I've tested it with Python 3.10 and Python 2.7. The branch is directly based on the source that you uploaded 2 weeks ago: https://github.com/ufo/PyCmd/tree/raw_fork_from_sourceforge_py3_compatible . So you could simply take a look at the diff and maybe merge...
I know it's been a while (life distracted me away from this project :| ) but I am now trying to revive the development a little bit. Therefore: Thanks for the patch! If you are still around and can still remember your idea, I would like to understand the problem that your patch solves: the abbrev_prompt() function is used exclusively by the prompt afaik, and cd-ing to a UNC path doesn't work anyway due to a limitation in cmd.exe (I am actively looking for a workaround, but this is a different story)....
If the reason for this request is to avoid "polluting" the screen, the new "zsh" completion mode (should be on by default for a recent PyCmd, unless behavior.completion_mode is set it the init.py) helps: the list of completions is erased from the screen when no longer needed.
A small note here: the updated "zsh-style" completion mechanism which supports navigating the list (which btw is now default unless overridden by behavior.completion_mode in init.py) shares one more advantage with the "cyclic" mode: less garbage is left over on the screen (the list of completions is erased when no longer needed)
Just wanted to mention (might be relevant to some users) that the completion has since been improved along the proposed direction -- but still not quite to what was originally requested: after pressing Tab and seeing a list of possible completions, one can press the Down arrow to start navigating through the list (using Up/Down, Left/Right, PgUp/PgDown, type-to-filter). While this is still not as easy as cycling completions with Tab, it does make the job simpler e.g. when the list is relatively short....
Updated README and NEWS to mention ERRORLEVEL support
Fix "cd" with no arguments
Locate cmd.exe via %COMSPEC%
Don't show ERRORLEVEL=141
Improved coloring of the ERRORLEVEL in the prompt
Added tests for the run_command() function
Support DelayedExpansion for environment variables
Keep the last ERRORLEVEL in the environment
Move to Python 3 (and potentially to github)
Fix for when displaying a window overflows the current buffer
Added unit tests for the Window class
Crash when pressing tab after a wildcard completion appended a blank
zsh-style completions are now default
Interactive completions can now be filtered
Fix bug when displayed window overflows the buffer height
Internal utility function for printing debug messages
Status line (lines displayed out of total) in scrollable windows
More keys supported in interactive completion selection
Cleanup code that displays the Window content
Compute height of completion window based on available space
Hide cursor when erasing completions
Mentioned zsh completions in documentation
Reworked completion display mechanism
is there any plan to port pycmd to work with python3?
Hi, .pycs are absolutely ok when they're packed in a single executable and they're extracted on each run. However, when delivering an expanded folder structure, there is a risk of being deleted. When moving the Python interpreter and/or projects, the first thing I do is to delete all .pyc files to reduce file count and archive size. Also, I have configured the cleaning tools to delete .pyc files. In my case, adding an exception for PyCmd won't be fun (I tend to keep a separate copy per Python interpreter...
Hi, the files are actually collected by cxFreeze; it seems to prefer the .pycs (they are presumably faster to load). I could try to find a way to tell cxFreeze to go with .py files instead; but first I would like to understand the problem that you are having -- what is the concrete drawback of the current (.pyc based) approach?
Hi, in the latest release some python modules are available only as *.pyc files, which are usually considered safe to delete (since they're recreated on demand). Is it possible to also ship the corresponding *.py files?
Fix broken repaint when prompt for large completion scroll is denied
Scroll buffer to show previous output after printing completions
When the init.py executes, __file__ now points to it
Option to toggle completion behavior (bash vs. zsh)
Completions are now shown below the prompt (zsh-style)
zsh-completions: auto-update completions as you type
Re-scan default console colors in case the /k command changed them
zsh completions: stop auto-complete on new token
Improved fix for pywintypes27.dll in Py64
Add platform to the build information
Completions are now shown below the prompt (zsh-style)
svn prompt: show dirty marker when files have been added
Fix git prompt when not on a tracking branch
git and svn prompts now use absolute colors
PyCmd failed to start (exception) when dir_history was missing
Updated NEWS.txt; build now adds header automatically
Re-fix Makefile for Py64 (missing Pywintypes27.dll)
Default prompt shows git and svn status
git and svn prompts use the simple_prompt to display the (abbrev) path
Build fixes
History save limit bumped from 1000 commands to 2000
Corrected version number
Minor README addition
Improved git prompt in example init.py file
Improved git-prompt in the example initialization file
Typing replaces selection
Properly store selection states with extend/shrink