Steps Towards easier PS Core

[TiddlyTweeter]

In my latest polly-01Na-TT.ps1

• one thing I did was go through the code and where there was hard-code of pathing I changed it from Windows to Unix/Mac style. Windows works fine with it so why not?

• I updated lots of "aliases" in code to full cmdlet names.

• an issue is how #CONSOLE settings are handled on different platforms. I haven't found much documentation on the topic yet. I treat it as an open issue.

• It matters in the sense that whilst you can natively just run PS scripts, the ability to launch them from shell scripts like .bat & .sh helps unify the experience.

• Its actually, on Windows, the console settings that permit a smooth transition, and harmonisation of look, between bat and PS script. Bat sets up run conditions.

• I don't use either Linux or Mac so I'm a bit limited in knowing options around both the console thing or command lines in their .sh files.

[Marxsal]

The screens looked good to me on Linux, despite the buffer setting being unusable (what was that supposed to do?). Maybe I'll take a screen shot when I get your 1Na rolled in. I feel we don't have to worry about the shell scripts right-away. Anyone who installs PS on Linox will probably have no trouble launching the ps1 file. For shell scripts to run, they need some magic #/bin (or something like that) at the top, and to be marked as executable. Unfortunately, the executable marking doesn't stick when you zip the file. So we would either need to provide that step in the documentation, and/or distribute the files in a GH "release" using tar/zip (tar can retain settings). Distributing things through the release is probably a good thing to do anyways.

Like you, I'm not sure what Mac will want.

Should I be looking for the polly-01Na-TT.ps1 file somewhere?

Thanks!

[TiddlyTweeter]

https://drive.google.com/file/d/12auDrY6Kg5PFkyZjqAR2JRDEaF4WZB_x/view I put it up via GG.

…

On Wed, 14 Aug 2019, 22:05 Marxsal, ***@***.***> wrote: The screens looked good to me on Linux, despite the buffer setting being unusable (what was that supposed to do?). Maybe I'll take a screen shot when I get your 1Na rolled in. I feel we don't have to worry about the shell scripts right-away. Anyone who installs PS on Linox will probably have no trouble launching the ps1 file. For shell scripts to run, they need some magic #/bin (or something like that) at the top, and to be marked as executable. Unfortunately, the executable marking doesn't stick when you zip the file. So we would either need to provide that step in the documentation, and/or distribute the files in a GH "release" using tar/zip (tar can retain settings). Distributing things through the release is probably a good thing to do anyways. Like you, I'm not sure what Mac will want. Should I be looking for the polly-01Na-TT.ps1 file somewhere? Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11?email_source=notifications&email_token=AG36WTNI3RIQDKINTBKNSMDQERQRJA5CNFSM4ILYGGY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4J6N2I#issuecomment-521397993>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG36WTL6QLTP3G6CUSBNWYTQERQRJANCNFSM4ILYGGYQ> .

[TiddlyTweeter]

The screens looked good to me on Linux, despite the buffer setting being unusable (what was that supposed to do?)

Buffer on Windows is the sizing of the "inner space" of the console. So you have, say, a console window set to 60 columns wide but output text will wrap at 60. So you set the Buffer to a higher number, say 160 wide & 5000 high. This buffer width means text will be better displayed for long lines you don't want wrapping and ruining they layout. And the height ensures that enough data is retained so you can scroll back a long way if needed.

The issue is only visible (on Windows) in Polly for wide directory listing / long paths.

Q: What happens on Linux?

UPDATE: I found another way to set console Buffer & Window sizes I'll add it to my next version to see if it works universally.