pushd popd 'down' and 'next'

[rayandrews]

I've got AutoHotkey giving me back my Alt+Up as 'pushd ^ cd ..' and Alt+Left as 'popd', so I'm happy (tho I'd be happier if TCC could give me control of those keys). In DOS, I'd have Alt+Down call 'down.com' which just moves from the current directory to the first subdir under it (if any), and Alt+Right call 'next.com', which moves to the next directory at the current level.

Are there Win32 compatible versions of these utilities, or, even better, does TCC have such functionality built in?

 

[Kachupp]

look at keystack

> -----Original Message-----
> From: rayandrews [mailto:]
> Sent: Thursday, 27 May 2010 3:39 p.m.
> To: [email protected]
> Subject: [Support-t-1998] pushd popd 'down' and 'next'
>
>
> I've got AutoHotkey giving me back my Alt+Up as 'pushd ^ cd ..'
> and Alt+Left as 'popd', so I'm happy (tho I'd be happier if TCC
> could give me control of those keys). In DOS, I'd have Alt+Down
> call 'down.com' which just moves from the current directory to
> the first subdir under it (if any), and Alt+Right call
> 'next.com', which moves to the next directory at the current level.
>
> Are there Win32 compatible versions of these utilities, or, even
> better, does TCC have such functionality built in?
>
>
>
>

 

[p.f.moore]

Alt+Down call 'down.com' which just moves from the current directory to the first subdir under it (if any), and Alt+Right call 'next.com', which moves to the next directory at the current level.

Are there Win32 compatible versions of these utilities, or, even better, does TCC have such functionality built in?

down -

cd %@quote[%@findfirst[*,d]]

You could probably implement next with a bit of juggling with %@findnext, but it would be uglier...

(You should also probably execute %@findclose[] to release the search handle, but I'm not sure what's the best way to do that -

cd %@quote[%@findfirst[*,d]]%@instr[0,0,%@findclose[]]

works, but looks pretty ugly...)

Paul.

 

[Jim Cook]

This might work to replace down.

alias down=`cd %@quote[%@execstr[*dir /ad /b]]`

This is ugly, and doesn't work once you get folder names that have awkward
characters, or in some folder names that are included in other folder names
(e.g. Z and FUZZY), but it works to replace next for that subset of folders.
Maybe you can work more with it to solve your problem, or maybe it'll work
as is. I tried to change the ffind to use /e"^...$", but ran into troubles
because of the embedded quotes.

alias next=`*cd ..\%@execstr[*dir .. /b /a:d | *head /n+%@word["[ ]",0,%@ex
ecstr[*dir .. /b /a:d | *ffind /l /k /m /t%@word["\",-0,%_cwd]]]]`

On Thu, May 27, 2010 at 12:26 AM, p.f.moore <> wrote:

> ---Quote (Originally by rayandrews)---
> Alt+Down call 'down.com' which just moves from the current directory to
> the first subdir under it (if any), and Alt+Right call 'next.com', which
> moves to the next directory at the current level.
>
> Are there Win32 compatible versions of these utilities, or, even better,
> does TCC have such functionality built in?
> ---End Quote---
> down -
> Code:
> ---------
> cd %@quote[%@findfirst[*,d]]
> ---------
> You could probably implement next with a bit of juggling with %@findnext,
> but it would be uglier...
>
> (You should also probably execute %@findclose[] to release the search
> handle, but I'm not sure what's the best way to do that -
>
>
> Code:
> ---------
> cd %@quote[%@findfirst[*,d]]%@instr[0,0,%@findclose[]]
> ---------
> works, but looks pretty ugly...)
>
> Paul.
>
>
>
>
>

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.

 

[vefatica]

On Thu, 27 May 2010 10:01:11 -0400, Jim Cook <> wrote:

|This might work to replace down.
|
|alias down=`cd %@quote[%@execstr[*dir /ad /b]]`

I could easily implement stuff like that at the plugin level (4UTILS seems
appropriate) ... say a command to move to the first subdirectory (according to
FindFirstFile() (FindNextFile() ...), and a command to move to the next
dubdirectory (same order) at the same level as the first (as from c:\a to c:\b)
... maybe DIRDOWN and DIRNEXT. With keystroke aliases (and some for "cd .." and
"cd -") you could move around a tree quite quickly. Are there any suggestions?
--
- Vince

 

[vefatica]

Or maybe DIRIN (first at the next level) and DIRDOWN/DIRUP (next/previous at the same level).

On Thu, 27 May 2010 10:01:11 -0400, Jim Cook <> wrote:

|This might work to replace down.
|
|alias down=`cd %@quote[%@execstr[*dir /ad /b]]`

I could easily implement stuff like that at the plugin level (4UTILS seems
appropriate) ... say a command to move to the first subdirectory (according to
FindFirstFile() (FindNextFile() ...), and a command to move to the next
dubdirectory (same order) at the same level as the first (as from c:\a to c:\b)
... maybe DIRDOWN and DIRNEXT. With keystroke aliases (and some for "cd .." and
"cd -") you could move around a tree quite quickly. Are there any suggestions?
--
- Vince

 

[Jim Cook]

For commands to change the directoryI think the names would be more
intuitive to me if they began with CD, like CDIN, CDBACK / CDPREV, CDNEXT or
something like that. The DIR prefix implies something else to me. Now, if
you were exporting variables %DIRIN, etc., then that would probably be a
better implementation, and the name prefix feels good to me. I don't get the
right impression from DOWN/UP however. UP feels like .. to me, not adjacent
to me. I'd probably choose BACK or PREV or LAST and NEXT. I suppose LAST
could be ambiguous also. Is the last folder the most recent one, or the
ultimate one?



On Thu, May 27, 2010 at 11:10 AM, vefatica <> wrote:

> Or maybe DIRIN (first at the next level) and DIRDOWN/DIRUP (next/previous
> at the same level).
>
>
>
> ---Quote (Originally by vefatica)---
> On Thu, 27 May 2010 10:01:11 -0400, Jim Cook <> wrote:
>
> |This might work to replace down.
> |
> |alias down=`cd %@quote[%@execstr[*dir /ad /b]]`
>
> I could easily implement stuff like that at the plugin level (4UTILS seems
> appropriate) ... say a command to move to the first subdirectory (according
> to
> FindFirstFile() (FindNextFile() ...), and a command to move to the next
> dubdirectory (same order) at the same level as the first (as from c:\a to
> c:\b)
> ... maybe DIRDOWN and DIRNEXT. With keystroke aliases (and some for "cd
> .." and
> "cd -") you could move around a tree quite quickly. Are there any
> suggestions?
> --
> - Vince
> ---End Quote---
>
>
>
>

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.

 

[vefatica]

On Thu, 27 May 2010 14:46:28 -0400, Jim Cook <> wrote:

|For commands to change the directoryI think the names would be more
|intuitive to me if they began with CD, like CDIN, CDBACK / CDPREV, CDNEXT or
|something like that. The DIR prefix implies something else to me. Now, if
|you were exporting variables %DIRIN, etc., then that would probably be a
|better implementation, and the name prefix feels good to me. I don't get the
|right impression from DOWN/UP however. UP feels like .. to me, not adjacent
|to me. I'd probably choose BACK or PREV or LAST and NEXT. I suppose LAST
|could be ambiguous also. Is the last folder the most recent one, or the
|ultimate one?

I agree about CD (vs. DIR).

How about CDNEXT/CDPREV to stay at the same level and CDDOWN (or CDIN?) to go to
the first available subdir.
--
- Vince

 

[Jim Cook]

I like those names. I think that providing variables might be more
flexible since cd %variable would do the command, but the the variable
could be used otherwise.

Sent from Cookie's iPhone
Jim Cook

On May 27, 2010, at 13:41, vefatica <> wrote:

> On Thu, 27 May 2010 14:46:28 -0400, Jim Cook <> wrote:
>
> |For commands to change the directoryI think the names would be more
> |intuitive to me if they began with CD, like CDIN, CDBACK / CDPREV,
> CDNEXT or
> |something like that. The DIR prefix implies something else to me.
> Now, if
> |you were exporting variables %DIRIN, etc., then that would probably
> be a
> |better implementation, and the name prefix feels good to me. I
> don't get the
> |right impression from DOWN/UP however. UP feels like .. to me, not
> adjacent
> |to me. I'd probably choose BACK or PREV or LAST and NEXT. I suppose
> LAST
> |could be ambiguous also. Is the last folder the most recent one, or
> the
> |ultimate one?
>
> I agree about CD (vs. DIR).
>
> How about CDNEXT/CDPREV to stay at the same level and CDDOWN (or
> CDIN?) to go to
> the first available subdir.
> --
> - Vince
>
>
>
>

 

[vefatica]

On Thu, 27 May 2010 18:18:43 -0400, Jim Cook <> wrote:

|I like those names. I think that providing variables might be more
|flexible since cd %variable would do the command, but the the variable
|could be used otherwise.

I suppose you mean something like

_CDNEXT = next dir at current level
_CDPREV = previous dir at current level
_CDDOWN = first subdirectory

Changing directory is hardly any work (one line in a plugin) and they won't be
of much use if you don't actually CD to them. So why not let the plugin do the
CDing? Do any other folks have opinions?

In my command versions, they beep if there is no next, previous, or lower
(respecively) directories. What should variables do in these cases ... return
an empty string?
--
- Vince

 

[rayandrews]

Gentlemen:

Thanks for the feedback, I've been fooling around with some of the suggestions but I've run into an inexplicable problem with %@execstr. For example:

echo %@execstr[dir]

returns:

The system cannot find the path specified.
"C:\DOUME1\RAY\LOCALS1\TEMP\EXE135.TMP"

I get that msg. regardless of how or where I use '%@execstr'

Thoughts?

 

[vefatica]

On Thu, 27 May 2010 23:43:35 -0400, rayandrews <> wrote:

|echo %@execstr[dir]
|
|returns:
|
|The system cannot find the path specified.
|"C:\DOUME1\RAY\LOCALS1\TEMP\EXE135.TMP"
|
|I get that msg. regardless of how or where I use '%@execstr'

Without an alias for DIR, this should happen:

v:\> echo %@execstr[dir]
ECHO is OFF

because the first line of DIR's output is empty. Do you have an alias for DIR?

And some lines of DIR's output contain the less-than and greater-than symbols
(the subdirectory lines). If you try to ECHO one of those lines without
protection, they'll be interpreted as indicating redirection to/from a file,
which could produce an error message such as yours.
--
- Vince

 

[p.f.moore]

Without an alias for DIR, this should happen:

v:\> echo %@execstr[dir]
ECHO is OFF

because the first line of DIR's output is empty. Do you have an alias for DIR?

And some lines of DIR's output contain the less-than and greater-than symbols
(the subdirectory lines). If you try to ECHO one of those lines without
protection, they'll be interpreted as indicating redirection to/from a file,
which could produce an error message such as yours.

Purely out of curiosity, the %@EXECSTR approach seems to caught people's interest more than my use of %@FINDFIRST. Is there a reason for that? My instinct would be to avoid EXECSTR where possible, because I'd assumed it would be slower - am I wrong?

Paul.

 

[rayandrews]

Purely out of curiosity, the %@EXECSTR approach seems to caught people's interest more than my use of %@FINDFIRST. Is there a reason for that? My instinct would be to avoid EXECSTR where possible, because I'd assumed it would be slower - am I wrong?

Paul.

Paul,

For the record, I found you method simpler and more effective, so far at least. However I'd still like to know what's going on with EXECSTR here. I used the examples in the 'help' verbatim and still get the above problem.
AFAICT, EXECSTR is trying to redirect to a temporary file and can't do it.

 

[rayandrews]

On Thu, 27 May 2010 23:43:35 -0400, rayandrews <> wrote:

|echo %@execstr[dir]
|

because the first line of DIR's output is empty. Do you have an alias for DIR?

And some lines of DIR's output contain the less-than and greater-than symbols
(the subdirectory lines). If you try to ECHO one of those lines without
protection, they'll be interpreted as indicating redirection to/from a file,
which could produce an error message such as yours.
--
- Vince

Vince,

Nope, it's nothing like that. Any use of EXECSTR produces the same result:

echo %@execstr[1,dir]
echo %@execstr[ver]
echo %@execstr[2,*dir]
etc.

... inside our outside batchfiles

There is some issue with temporary files because each attempt to use EXECSTR creates a new sequentialy named file:

EXE6.tmp
EXE7.tmp
etc.

TCC: (Sys) The system cannot find the path specified.
"C:\DOCUME1\ ... \EXE7.tmp"
TCC: (Sys) The system cannot find the file specified.
"%@execstr[1,(dir) >!"C:\DOCUME1\ ... \EXE7.tmp]"

the path it's looking at is my %temp% so I figure EXECSTR is trying to capture the output of DIR to a temporary file there but can't do it.

 

[rayandrews]

Vince,


the path it's looking at is my %temp% so I figure EXECSTR is trying to capture the output of DIR to a temporary file there but can't do it.

Yup, that's it.

set tmp=c:\temp

... and EXECSTR now works fine.


So, what's wrong with that previous %tmp% ?
Path too long?
TCC doesn't like the LFN's?

Where does XP make it's environment settings?
Can I change %tmp% at startup?

 

[vefatica]

On Fri, 28 May 2010 10:27:13 -0400, rayandrews <> wrote:

|So, what's wrong with that previous %tmp% ?
|Path too long?

This one: "C:\DOUME1\RAY\LOCALS1\TEMP"?

No, the path's not too long. Does it exist? Do you have write-access to it?
|TCC doesn't like the LFN's?

TCC loves LFNs! My computers do not gererate SFNs at all.
|
|Where does XP make it's environment settings?

ControlPanel\System\Advanced\EnvironmentVariables

|Can I change %tmp% at startup?

At startup of what?
--
- Vince

 

[Steve Fabian]

----- Original Message -----
From: "vefatica" <>

> I suppose you mean something like
>
> _CDNEXT = next dir at current level
> _CDPREV = previous dir at current level
> _CDDOWN = first subdirectory
>
> Changing directory is hardly any work (one line in a plugin) and they
> won't be
> of much use if you don't actually CD to them. So why not let the plugin
> do the
> CDing? Do any other folks have opinions?

Since different people would want to use different names for the commands,
if all you provide is the internal variables, they can craft their own
trivially simple aliases, which (since this is normally done only
interactively) is just as fast as combining the name and command. I.V. names
would not pollute the namespace. Adding the commands would, though only
minimally.

>
> In my command versions, they beep if there is no next, previous, or lower
> (respecively) directories. What should variables do in these cases ...
> return
> an empty string?

Yes.
--
Steve

 

[vefatica]

On Fri, 28 May 2010 11:14:06 -0400, Steve Fábián <> wrote:

|Since different people would want to use different names for the commands,
|if all you provide is the internal variables, they can craft their own
|trivially simple aliases, which (since this is normally done only
|interactively) is just as fast as combining the name and command. I.V. names
|would not pollute the namespace. Adding the commands would, though only
|minimally.

ftp://lucky/syr.edu/4plugins/4utils.zip

I uploaded a new 4UTILS plugin (32-bit only). It has all six, CDIN, _CDIN,
CDNEXT, _CDNEXT, CDPREV, and _CDPREV. On failure, the three commands return 1
and, outside a batch file, beep. They could use some testing.

I completely ignore "System Volume Information" since you can't do anything with
it. Are there any other such directories?
--
- Vince

 

[Steve Fabian]

----- Original Message -----
From: "Jim Cook" <>

>
> Re: System Volume Information, http://support.microsoft.com/kb/309531
> shows
> how to get access to it.
>
> In general, if one of your CD functions can not get access to the
> in/next/prev folder because of permissions or any other failures, do they
> ignore that failure and try with the next folder in sequence? I can
> imagine
> cases where I would want the "Permission Denied" message, but many more
> where CDNEXT/_CDNEXT go to the next folder I can get to.
>

There could be an option in the command what to do in the above situation,
allowing to choose between error message and pause before going to next
directory, error message without pause, or just skipping over, with an
optional terminal report.
--
Steve

 

[vefatica]

On Fri, 28 May 2010 13:23:46 -0400, Jim Cook <> wrote:

|In general, if one of your CD functions can not get access to the
|in/next/prev folder because of permissions or any other failures, do they
|ignore that failure and try with the next folder in sequence? I can imagine
|cases where I would want the "Permission Denied" message, but many more
|where CDNEXT/_CDNEXT go to the next folder I can get to.

If you can't CD there, you can't continue with CDNEXT or CDPREV (because they go
through the subdirs of the parent of the current dir). That's why I ignore it.
I suppose I could test every dir returned by FindNextFile (by trying to
enter/leave) and give a message like "skipping inaccessible ..." and then just
skip it ... wouldn't bee too hard but I wonder how useful it'd be. Do you ever
run across other dirs you can't enter? I figure folks would not generally use
those tools where they don't have access to everything (except SysVolInfo).
--
- Vince

 

[Jim Cook]

On Vista, something has made folders that I don't have permission to go
into, so skipping errors is probably what I'd do. Something like a for(;;) {
if (chdir()) break; FindNext}


On Fri, May 28, 2010 at 11:06 AM, vefatica <> wrote:

> On Fri, 28 May 2010 13:23:46 -0400, Jim Cook <> wrote:
>
> |In general, if one of your CD functions can not get access to the
> |in/next/prev folder because of permissions or any other failures, do they
> |ignore that failure and try with the next folder in sequence? I can
> imagine
> |cases where I would want the "Permission Denied" message, but many more
> |where CDNEXT/_CDNEXT go to the next folder I can get to.
>
> If you can't CD there, you can't continue with CDNEXT or CDPREV (because
> they go
> through the subdirs of the parent of the current dir). That's why I ignore
> it.
> I suppose I could test every dir returned by FindNextFile (by trying to
> enter/leave) and give a message like "skipping inaccessible ..." and then
> just
> skip it ... wouldn't bee too hard but I wonder how useful it'd be. Do you
> ever
> run across other dirs you can't enter? I figure folks would not generally
> use
> those tools where they don't have access to everything (except SysVolInfo).
> --
> - Vince
>
>
>
>
>

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.

 

[vefatica]

On Fri, 28 May 2010 14:06:25 -0400, Steve Fábián <> wrote:

|There could be an option in the command what to do in the above situation,
|allowing to choose between error message and pause before going to next
|directory, error message without pause, or just skipping over, with an
|optional terminal report.

You wouldn't like an error message! Every time you CDNEXT or CDPREV, they go
through all the subdirs up to _CDNEXT. If you're already beyond an inaccessible
one you'd see the message every time you CDNEXT'd or CDPREV'd. With the current
design that would be hard to work around.

I could make it ***MUCH MORE COMPLICATED*** by enumerating the sibling dirs once
and for all (updating when %_cwd changes) and then just going through a list
every time you CDNEXT ot CDPREV. I'm not in any hurry to do that!

I added a generic test for accessibility (seems to be OK) but discovered a
glaring omission ... I didn't update the DirHistory! It'll take a little while
to do that and I have a couple of chores to do. I'll be back!
--
- Vince

 

[vefatica]

I added a generic test for accessibility (seems to be OK) but discovered a
glaring omission ... I didn't update the DirHistory! It'll take a little while
to do that and I have a couple of chores to do. I'll be back!

I also made to update the dirhistory and the "CD -" mechanism. New one uploaded.

ftp://lucky.syr.edu/4plugins/4utils.zip

 

[rayandrews]

On Fri, 28 May 2010 10:27:13 -0400, rayandrews <> wrote:

|So, what's wrong with that previous %tmp% ?
|Path too long?

This one: "C:\DOUME1\RAY\LOCALS1\TEMP"?

- Vince

Vince,

Thanks for the input. It turns out that the bug is due to my using the tilde as my ESCAPECHAR which fouled up the LFNs shorname dislplay. I noticed that 'DOCUME~1' became 'DOCUME1' and that gave it away.

So, as previously suggested, I'm now using EscapeChar=24 in tcmd.ini -- I hope that's finaly safe although I have a vague recollection of trouble there, too.

 

[rayandrews]

I also made to update the dirhistory and the "CD -" mechanism. New one uploaded.

ftp://lucky.syr.edu/4plugins/4utils.zip

Vince,

Grabbed 4utils.zip, but what do I do with it now? How does the .dll work?
And, how do you do that? -- add something to TCC?

 

[rayandrews]

Vince,

Grabbed 4utils.zip, but what do I do with it now? How does the .dll work?
And, how do you do that? -- add something to TCC?

Asked too soon, this is a 'plugin', once I have the term, the help page told me how to make it work. But I'd still like to know how one makes such a thing. Most cool of Rex to give us this level of power.

The help page mentions keyboard control. Does that mean that it would be possible to capture the 'Alt+' keystrokes that I now need AutoHotKey to control?

 

[vefatica]

On Fri, 28 May 2010 20:38:46 -0400, rayandrews <> wrote:

|---Quote (Originally by vefatica)---
|I also made to update the dirhistory and the "CD -" mechanism. New one uploaded.
|
|ftp://lucky.syr.edu/4plugins/4utils.zip
|---End Quote---
|Vince,
|
|Grabbed 4utils.zip, but what do I do with it now? How does the .dll work?
|And, how do you do that? -- add something to TCC?

To use the DLL, put it in a "Plugins" subdirectory of TCC's home. Plugins there
are automatically loaded when TCC starts. Also see the PLUGIN command (for
manual loading/unloading/...).

To extend TCC, you build a DLL with a simple overall structure dictated by Rex's
plugin interface and simply (almost) export commands, variable functions, and
internal variables like:

INT WINAPI MYCOMMAND ( WCHAR *psz );
INT WINAPI f_MYFUNCTION ( WCHAR *psz );
INT WINAPI _MYVARIABLE ( WCHAR *psz );

When parsing commands, TCC augments its internal lists of commands, variable
functions, and internal variables with those found in plugins. To the user it
seems they're part of TCC.

Here's a link to the plugin Software Development Kit (SDK)

ftp://ftp.jpsoft.com/sdk/sdk.zip

It contains a sample plugin. Nearly 100% of the documentation is in TakeCmd.h
There are 5 (or so) plugin authors who frequent these forums. I suppose they'll
be glad to help.
--
- Vince

 

[vefatica]

On Fri, 28 May 2010 20:54:03 -0400, rayandrews <> wrote:

|The help page mentions keyboard control. Does that mean that it would be possible to capture the 'Alt+' keystrokes that I now need AutoHotKey to control?

Yes. Do that by exporting the likes of

INT WINAPI QKHANDLER( LPKEYINFO lpKeyInfo )

informing TCC by marking it with an asterisk, thus:

LPPLUGININFO WINAPI GetPluginInfo( VOID )
{
static PLUGININFO pluginfo = { L"QKEY", L"Vincent Fatica",
L"moc.rr.yncwt@snigulp", NULL, L"Key Mappings", L"QKEY,*QKHANDLER",1,1,3,0 };
return &pluginfo;
}

Your KEYHANDLER is called with (almost) every keystroke, and info about the
keystroke is supplied.

You might try ftp://lucky.syr.edu/4plugins/qkey.zip

Read the TXTfile. QKEY is solely devoted to handling keystrokes and its
"showkey" routine will help you get key codes (not all are documented).
--
- Vince

 

[rayandrews]

On Fri, 28 May 2010 20:38:46 -0400,

To extend TCC, you build a DLL with a simple overall structure dictated by Rex's
plugin interface and simply (almost) export commands, variable functions, and
internal variables like:

INT WINAPI MYCOMMAND ( WCHAR *psz );
INT WINAPI f_MYFUNCTION ( WCHAR *psz );
INT WINAPI _MYVARIABLE ( WCHAR *psz );

When parsing commands, TCC augments its internal lists of commands, variable
functions, and internal variables with those found in plugins. To the user it
seems they're part of TCC.

Here's a link to the plugin Software Development Kit (SDK)

ftp://ftp.jpsoft.com/sdk/sdk.zip

It contains a sample plugin. Nearly 100% of the documentation is in TakeCmd.h
There are 5 (or so) plugin authors who frequent these forums. I suppose they'll
be glad to help.
--
- Vince

Many thanks Vince, I'm off to the races, being able to extend TCC sounds like fun, I'm not a bad C programmer myself. Do you/we share SRC? I learn best by mimicry and expansion.