Good Day -

With your permission i am going to post questions re 6.4-6.5 migration here. If you prefer PM let me know.

1. Is there a way to default the dir/long switch in miame.ini or anywhere to show long filenames w/o specifying every time? I know i could create my own .do file but that seems clunky.

Ty

There isn't yet, but we're working on it. The system parameter (miame.ini) setting OPTIONS=LONGDIR will set the DIR output to 10.4, and that's been the case since the 10.3 filename format was adopted years ago. That setting also sets the /W display to three columns instead of four.

We haven't yet settled on the best way to handle permanent display of the filenames in something other than 10.4. But there will be something, probably OPTIONS=LONGDIR,20,6, coming along soon. Stay tuned to the Dev Notes.

Thank you Sir.

We have been using the LONGDIR feature for a while, your suggestion looks good.

Unfortunately, adding a modifier to the end of OPTIONS=LONGDIR doesn't really fit into the design, since all of the OPTIONS are single bit on/off values. So if we're to add an INI file parameter to set the default for the DIR/L:##.# switch, it would have to be an entirely new directive, which I'm not overly thrilled about.

Far too many neurons have been overworked by this issue already, and I'm beginning to question how much more (or what kind of) effort is warranted to avoid having to type the /L:##{.#} parameter in your DIR command lines.

On the one hand, I can appreciate that you'd rather type DIR than DIR/L:30. But once we get beyond 10.4, how sure can you be of the ideal size you want to set as the default? 14? 20? 32?

Note that the traditional DIR command display format with the extensions lined up in their own column separated from the names looks reasonable when the names generally fill out the space provided, as was the case with 6.3 and even 10.3. But if you change the default to, say, 25.4, then it starts to look kind of goofy, e.g.
Switching to the native format using the /NA switch gives you a combined name.ext width of 32 but eliminates the weird spacing between the names and extensions, possibly being a better default for many people in your situation, e.g.

But it does come with case sensitivity, and a switch to sizes in bytes rather than our somewhat arbitrary and anachronistic "blocks".

Or, for another perspective, if you've looked at the DIR/? display lately, you'll be reminded that there are something like 27 switches available, many of them taking sub-arguments. Is there that strong of an argument for elevating just this one to MIAME.INI status (which also implies adding a corresponding SET option, as well as another MX_xxxx option to get and set it)?

What are the alternatives?

One would be to just get used to typing a few more characters to get the desired switches/options/format you want (which if you're anything like me, changes from moment to moment anyway).

Another would be to create a XDIR.DO with your preferred switches and then teach your users (or support staff?) to type XDIR instead of DIR.

Yet another would be to confine any configuration upgrades to just DIR by creating a DIR.INI file. That would have the additional benefit of allowing the default width (and perhaps other options) to be fine-tuned to the kinds of files stored in a particular directory. But, it might lead to more configuration file proliferation and possible confusion over why DIR acts differently in different situations.

I've always just done a host ls -lt | more from the dot prompt to cover most other non-feature supported DIR options, I think the ls command covers mostly everything needed.

I guess I also do this as its easier to remember than learn new parameters, I still dont even use /UDATE as ls -lt shows it.

I suspect that your approach is just one of the many variations/adaptations that people facing the problem of non-conforming native filenames has adopted. Although you're not not even looking for a new solution at this point, if you were, I might suggest the XDIR.DIR.

(You might also consider using the HOST /O switch so that the display gets created A-Shell rather than the host OS, thus keeping the cursor in sync with the display.)

HOST/O I've learnt something new! Thanks..

"Far too many neurons have been overworked by this issue already, and I'm beginning to question how much more (or what kind of) effort is warranted to avoid having to type the /L:##{.#} parameter in your DIR command lines"

I have seen arguments on this board that lasted weeks discussing how many nested if/else/ifelse/ifnot/maybe/maybenots.

And we are talking about defaulting the ashell directory into columns. Clearly this is asking too much of the OS. We will accommodate the issue locally.

Touché!

I didn't mean to imply that it wasn't a subject worth debating, as much as that it probably wasn't worth making a lot of changes to A-Shell (INI file, MX_xxx, SET.LIT, doc, etc.) just to change the default DIR display width, when there were a variety of other ways to accomplish the objective that were less intrusive and more flexible. And especially when it isn't at all clear, to me at least, that once we break out of the 10.3 box, there is any suitable default size, even within a single application.

In most of the program directories, 10.3 is probably perfect. But when you get into directories containing data files imported from other locations, you might need 30.4, or 50.4, and that would seem ridiculous for the program directories.

Also, Steve raises a valid point (with his ls -lt), that there are other options besides width that you might want to include in the default, assuming the objective is to avoid having to type several switches on the end of every DIR command (which is a reasonable desire).

It may also be worth discussing whether the existing OPTIONS=LONGDIR should simply be increased from 10.4 to, say, 16.4. That would be easy, but I'm a little worried that it irritate some users for changing something they don't view as broken, and others for being not nearly enough of a change.

But if we're looking for a better default DIR display format, and we're willing to change from the existing one, maybe borrowing an idea from ls -lt and putting the size first and letting the file.ext take up the rest of the line (like ls -lt) makes more sense, elegantly avoid the problem of how far over to put the size column, e.g.

I like that layout Jack...
Would it squeeze the last update date & time also between size and file name?

Maybe we should just add another switch, /LT, for an A-Shell-esque version of ls -lt?

I'm not sure I'm that enamored of the way ls -lt replaces the year with the hh:mm if it's the current year, but I guess it does give you more information, and does make sense that while you might care about the time of day for recent files, you surely wouldn't for files from last year. In that case, we'd go with something like this:

or, perhaps sticking to upper case (unless maybe the /NA switch added) ...

Now that DIR/LT looks just perfect (either case) and I would return from my UNIX command defection... but best check with Frank as i've hijacked his tread.

I do usually use it for as much for the "time" as much as the "date" seeing when and what the last files were updated.

Thanks for the reply.

Not trying to "gild the lily" here so to speak, just trying to improve on the display w/o all sorts of hoops.

I do realize we could just jump to the native OS syntax as noted earlier, but wouldn't that just bypass the MIAME prime directive?

So far i like the DIR option as above from Jack, with the option of adding the /LT switch. W/o upsetting current users and changing current usage could this be turned on using another OPTIONS=NEWDIR?

OR i acknowledge that if there is not an elegant solution i can write some scripts to capture the file info from the LS and pipe into a file to display... so if cannot decide on a good ashell addon that will be the route to take.

I'm not at all suggesting you should bypass DIR.LIT to go directly to the OS as Steve has been doing, since as you correctly point out, it undermines one of the advantages of environment independence provided by A-Shell/MIAME. (ls -lt would have no meaning under Windows, while DIR/LT would produce the same output as it would under Linux or AIX.)

So I'm happy to enhance DIR.LIT to provide whatever output is deemed desirable (like the proposed DIR/LT, which is on the to-do list now).

What I'm somewhat less enthusiastic about is trying to figure out ways to avoid typing DIR switches (e.g. DIR/L:24.5) that require modifications to A-Shell itself, some of the reasons being:

- Each MIAME.INI option typically requires changes to multiple independent areas of code: the INI parser, the internal structure holding all the current options, the MX_xxx functions that get/set the options, and possibly SET.LIT. That makes for a lot of coding (plus documentation) just to avoid a couple of characters of typing in DIR commands.

- To further complicate the problem, the option we're struggling with is not just an on/off switch but requires two sub-parameters (the maximum name length and the maximum extension length), and thus would require an entirely new MIAME.INI directive, and corresponding new MX_GETOPTIONS, MX_SETOPTIONS and SET.LIT functions.

- It isn't clear to me that for any given site, there is any suitable /L:xx.x value which will make the users at that site happy. My fear is that once you start accommodating the kinds of long file names you find in the real disk-directory-world, you'll find that 20, 30, 40, maybe even 50 characters isn't enough to handle them all. But setting the DIR standard format to support such long names renders most of the other aspects of traditional DIR formatting unwieldy. Do you really want your standard DIR output to look like this:

Adding any other display options, such as hash and update dates/times will end up spilling off the edge of the 80 column screen, wrapping the display and undermining the entire benefit of the traditional columnized formats.)

To put it another way, after having lived with 6.3 for a couple of decades, 10.3 seemed like it would offer the world, and at very little loss of usable space for those other display options, including even /W. But now, I have no expectation that even doubling the default size is going to significantly increase the percentage of files that can be displayed correctly. (If you're experience is anything like mine, 90+% of the files showing up in my directory listings fit within 10.4; increasing that to 20.4 might only increase the percentage from 90% to 95%. Going to 30.6 would increase it from 95% to 98%.) Is that really enough to justify the effort at implementing a centralized option, particularly when we at the same time lose valuable screen space that could be used for hash, version, and timestamps?)

- It's not obvious to me whether the goal is to shield users who currently type DIR commands to have to learn a new switch (in which case the you want to make the default large enough to cover nearly 100% of the files), or to simply reduce the frequency with which they have to type a few extra characters (in which case maybe only a small increase in the default make sense).

- As Steve's DIR/LT idea illustrates, it's likely that the ideal default DIR display (with no switches) might well include other options beyond just display width, i.e. timestamps, and bytes-vs-blocks).

- Also as the DIR/LT idea suggests, rather than struggling over the ideal width to allow for the name and extension, maybe it would be smarter to change the layout entirely so that it's less of an issue, i.e. by putting the filename at the end of the line instead of the beginning.

Maybe it would make sense, rather than adding a MIAME.INI option to set the DIR width, to instead add one to toggle between "old" and "new" format, where the "new" format puts the filename at the end of the display, after all of the other optional display elements (size, timestamps, hash, version, etc.) At least in that case it would just be another OPTIONS bit, so wouldn't require more than a new bit flag for OPTIONS and MX_GETOPTIONS and MX_SETOPTIONS.

Understand the problems with all the housekeeping here. Seems a bit overkill right?

I am OK with a straightup change to DIR.LIT to add a new /lt switch, it seems like a fair option. That takes care of all the random filename sizes.

This is still a nice improvement over the current /L##.## option, while that preserves columns it does make the screen look wonky as you pointed out.

Ok then, let's start with adding DIR/LT. I'll try to hammer that out in the next day or so.

Thanks Cap.

FYI - trace message coming up when renaming a file at the prompt. Don't know if it is important... looks like perhaps just some old debugging tools. No local debug flags are set.

DEFOFILNAM=[*], DEFOEXT=[*], DEFIFILNAM=[*], DEFIEXT=[*]
PROCESS'ITEM:
if val(THISOP) <> val(THISIP) or val(THISOPN) <> val(THISIPN) or .THISODEV <> THISIDEV then
--> THISOP=[060], THISIP=[060], THISOPN=[100], THISIPN=[100], THISODEV=[DSK90], THISIDEV=[DSK90]
FULLISPEC = THISIDEV+":"+THISIFILNAM
--> FULLISPEC=[DSK90:POST], THISIDEV=[DSK90], THISIFILNAM=[POST]
if THISIEXT <> "" then FULLISPEC = FULLISPEC+"."+THISIEXT
--> THISIEXT=[BAS]
FULLISPEC = FULLISPEC+"."+THISIEXT
--> FULLISPEC=[DSK90:POST.BAS], THISIEXT=[BAS]
FULLISPEC = FULLISPEC+"["+str(val(THISIP))+","+str(val(THISIPN))+"]"
--> FULLISPEC=[DSK90:POST.BAS[60,100]], THISIP=[060], THISIPN=[100]
FULLOSPEC = THISODEV+":"+THISOFILNAM
--> FULLOSPEC=[DSK90:POST], THISODEV=[DSK90], THISOFILNAM=[POST]
if THISOEXT <> "" then FULLOSPEC = FULLOSPEC+"."+THISOEXT
--> THISOEXT=[REV]
FULLOSPEC = FULLOSPEC+"."+THISOEXT
--> FULLOSPEC=[DSK90:POST.REV], THISOEXT=[REV]
FULLOSPEC = FULLOSPEC+"["+str(val(THISOP))+","+str(val(THISOPN))+"]"
--> FULLOSPEC=[DSK90:POST.REV[60,100]], THISOP=[060], THISOPN=[100]
xcall MIAMEX,3,FULLISPEC,"","",2,DDB,FR
--> FULLISPEC=[DSK90:POST.BAS[60,100]], DDB=[DSK90 FR=[0]
xcall MIAMEX,26,FSPECSTR
--> FSPECSTR=[POST.BAS]
print FSPECSTR;" to ";
--> FSPECSTR=[POST.BAS]
xcall MIAMEX,3,FULLOSPEC,"","",2,DDB,FR
--> FULLOSPEC=[DSK90:POST.REV[60,100]], DDB=[DSK90 FR=[0]
xcall MIAMEX,26,FSPECSTR
--> FSPECSTR=[POST.REV]
print FSPECSTR;
--> FSPECSTR=[POST.REV]
if EQ call RENAME'FILE
--> EQ=[-1]

That slipped out without proper QA but was fixed shortly thereafter. The quickest fix is UPDCUR. Or wait for a new complete build sometime this week.

No worries. Thanks.

Ok, the new DIR 3.4(168) is available via UPDCUR under 6.5. (It also works under 6.4, so you could manually copy it over, but I'm reluctant to update the repository due to uncertainty about possible subtle differences.)

Note that in addition to the new /LT switch, there is also a /P which pages the output (essentially equivalent to PAGE DIR).

/LT working well, Thanks!
Now changing my ls.do from
to
Thanks.

Display works as advertised thanks.

Odd thing however is when using the /p flag, i get a "waiting on xxx.xxx.xxx.xxx" (linux server) message. I get page 1 with the --- more--- It won't wake up until i hit control-c.

If I try again using: page dir/lt

It displays fine w/o getting hung up. Seems like ATE is waiting for some sort of ack from ashell to wake up.

No hurry...

PS: Is the date the create date or the update date? Thanks.

pss new undocumented feature:

the /sname switch is ordering the output in reverse order (z to a).

The /P issue under ATE seems intermittent but it's proximate cause is clear enough - the terminal is in Kbd Local Mode (as you can see from the Settings menu). To be fixed shortly.

The date displayed with /LT is the update date (matching ls -lt). If you want the create or access date, you can add the /CDATE and/or /ADATE switches, but currently those continue to display in the standard DIR format, which seems a bit weird next to the /LT format, e.g.

That's even worse than weird, but the hybrid date/time format used for /LT is a bit weird in itself. I'm not really sure what the best approach is when combining "super-switches" like /LT with traditional ones like /CDATE and /CTIME. As a practical matter, it's probably not a big deal, since the update date is almost always the only one you really care about. But maybe for visual consistency we should have /LT convert all dates to the hybrid format used by /LT? (And then we ignore /xDATE?) Or maybe the reverse - stick to the traditional date and time formats except with /LT is used by itself? Or perhaps /LT/CDATE should keep the /LT format but swap out the update date with the creation date?

As for the sort order, traditionally all DIR sorts were (and still are) ascending, with the one exception being that /LT sorts descending. The wisdom there is debatable, but I was operating under the theory that at least part of the attraction of DIR/LT was it's familiarity to fans of ls -lt (with another part being it's ability to display much longer filenames without the columnization problem.) So it seemed sensible to retain it's sort order.

Incidentally, it was that sort order, with the most recent files at the top, that led me to add the /P switch, since in that mode, typically you're only interested in the first page-worth of files. (In contrast, with the ascending sorts, particularly on size or date, you typically just let it run to the end in order to see the biggest/newest files.)

DIR/LT/SNAME introduces a couple of problems with the sort logic though:

1) DIR doesn't currently allow you to specify more than one sort order, so it's not clear here which field you want to sort on - update or name?

2) Assuming name (since after all, there's no other reason to specify /SNAME), then probably we should stick with the ascending sort. (Currently the sort reversal flag from /LT is spilling over to the name sort.)

Beyond that, I've already been reprimanded by our documentation czar and head of design minimalisation for allowing too many switches in one command. So please don't anyone suggest that the solution to these growing conflicts between different switches is to add still more!

On the bright side, all of these issues are confined to DIR.LIT and don't require any further tinkering with A-Shell internals. So I'll plan on another update sometime in the next 24 hours or so. I the meantime, feel free to post additional gripes, suggestions, long-held secret desires, etc.

No good deed goes unpunished rares it's ugly head again!! :rolleyes:

Agreed - new features don't seem to play well with legacy switches. It's up to you if want /lt to just be a "super switch" and ignore all other switches... seems that would make sense.

As for sorting, if u want to /lt to be a super switch and just sort ascending based on most recent files at top. Probably need to put the nails in this coffin before you are tempted to climb in!!

I’m happy how /LT is now, don’t aim to to combine switches and like how it’s showing the last update date in descending order...
I’m easy pleased

That's why (or at least one of the many reasons why) we like you so much!

OUCH!!

Ty - cancel that order for the 150 node system we were chatting about...

PS: Steve is still smarting over the embarassing loss yesterday... he's not thinking clearly

Just to keep the peace, I've just updated DIR to 3.4(169), fixing the ATE /P keyboard issue and reverting to ascending sort for /LT/SNAME and /LT/SEXT, but not /LT/SSIZE. (If one likes the /LT format, presumably one is thinking in terms of being most interested in the files at the top of the list, and probably if sorting by sizes, it's the bigger files, not the smaller ones of most interest).

DIR/SSIZE without /LT remains ascending.

I haven't done anything about the mashup of formats you get when combining /LT with other /xDATE switches; will wait to see if that's an issue for anyone.

Use UPDCUR to get the update.

P.S. We like you too Frank. (Just for different reasons. :rolleyes: )

And you're right even without saying it: we should try to be magnanimous in victory. :p

Ha, sort of like the way Herman says "bless your heart" to me?!

As for being magnanimous.. cmon now, that ain't the way we Make America Great Again!!

As for DIR - thanks.. as far as i recall a whole few hours ago I think i also said leave it be the way it was, but guess it sounded better with a british accent?? :rolleyes: