Ability to recieve and transmit communication packets

Requirement
We must have the ability to be able to transmit and receive and decode the packets going to and from the ventilator control module as described in the Interface-Ventilator protocol document to be able to set the settings and receive telemetry back to display.

Blocked by #60

https://github.com/RespiraWorks/VentilatorSoftware/wiki/Alpha-milestone has been updated with more specific guidance for what is needed by 5/1. I have thus assigned priority label for #4 #6 #8 #22.


104047 Enable day cell customization in DateRangePicker

Follow up of: https://github.com/flutter/flutter/pull/105739
Solves https://github.com/flutter/flutter/issues/104047
This is a proof of concept PR and it is rather large because showDateRangePicker is a big monolithic source which did not have customization in mind when initially done. I think it would be worth to rethink some parts of it to be publicly accessible, for example _MonthItem could be used as a standalone widget. This PR already helps with that by exporting some of the business logic from the tree to a controller.
Allows the date range picker to be customized:

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: PickerExample(),
    );
  }
}

class PickerExample extends StatelessWidget {
  const PickerExample({super.key});

  void _showPicker(BuildContext context) {
    showDateRangePicker(
      context: context,
      firstDate: DateTime(2022, 06, 13),
      lastDate: DateTime(2023),
      dayItemBuilder: (context, date, controller, focusNode) {
        final isInRange = controller.verifyIsInAllowedRange(date);
        final isWednesday = date.weekday == 3;
        final isEnabled = isInRange && !isWednesday;
        TextStyle textStyle = isWednesday
          ? const TextStyle(color: Colors.orange)
          : const TextStyle(color: Colors.black);
        if (!isInRange) {
          textStyle = const TextStyle(color: Colors.red);
        }
        return DayItem(
          date: date,
          onTap: isEnabled ? () => controller.push(date) : null,
          focusNode: focusNode,
          controller: controller,
          textStyle: textStyle,
          selectionColor: isWednesday ? Colors.orange : Theme.of(context).colorScheme.primary,
        );
      },
    );
  }

  @override
  Widget build(BuildContext context) {
    return Center(
        child: ElevatedButton(
          child: const Text('open'),
          onPressed: () => _showPicker(context),
        ),
      );
  }
}

``

?

@darrenaustin may I have a review ? We are soon going to build on top of this so future changes will probably be dropped.

You are free to close this. I'm not going to follow up on it.

Closing per comment above. Thanks for your contribution! I agree that packages are probably a better solution to this.


Proposal for modular assembly of services in container

Proposal for modular assembly of services in container
Provide a simple mechanism to populate service definitions in a container that allows implementations to group related components together across frameworks/application
The current implementation has no opinion to how services are registered to the container which allows users to assembly their container(s) however you want. This is all well and good, but it would be nice to provide consumers of the framework an opinionated way to register their services. My proposal is to provide an AssemblyType and Assembler to provide such a feature. This approach would allow sane bootstrapping of the container (this concept is taking from is very vaguely taken from Typhoon
Proposed Implementation
There are 2 components to the implementation: AssemblyType and Assembler. The AssemblyType provides an interface that can be implemented by classes/structs (depending on your use case) that is provided a container from elsewhere.
protocol AssemblyType {
    func assemble(container: Container)
}

The Assembler will take a list of AssemblyType instances and build the container. The Assembler will either:
a) Own the container
b) Create the container to be owned else where
The implementation would be really straight forward:
class Assembler {
   let container = Container()
   init(assemblies: [AssemblyType]) {
       for assembly in assemblies {
           assembly.assemble(container)
       }
   }
}

With this approach, one can separate their service definitions like so:
class ServiceAssembly: AssemblyType {
    func assemble(container: Container) {
        container.register(FooServiceType.self) { r in
             FooService()
        }
        container.register(BarServiceType.self) { r in
            BarService()
        }
    }
}

class ManagerAssembly: AssemblyType {
    func assemble(container: Container) {
        container.register(FooManagerType.self) { r in
            FooManager(service: r.resolve(FooServiceType.self)!)
        }
        container.register(BarManagerType.self) { r in
             BarManager(service: r.resolve(BarServiceType.self)!)
        }
    }
}

Now like service definitions are grouped and we can build our container like so:
let assembler = Assembler(assemblies: [
    ServiceAssembly(),
    ManagerAssembly()
])
let container = assembler.container // will contain all registered services

Additionally, this provides an easy means to override service definitions with mocks using inheritance. Let's say we want to replace FooService with MockFooService:
class MockServiceAssembly: ServiceAssembly {
    override func assemble(container: Container) {
        super.assemble(container)

        container.register(FooServiceType.self) { r in
             MockFooService()
        }
    }
}

Then we would load our assembler with the MockServiceAssembly instead:
let assembler = Assembler(assemblies: [
    MockServiceAssembly(),
    ManagerAssembly()
])

Thank you for your idea to add the feature! It is convenient and helpful for users who have used Typhoon or another DI framework supporting the assembly feature (if exists). The implementation plan is perfect👍
What I am thinking about new feature is structuring Swinject project. When I got PR #14, I thought extended features should be in another repository to organize the project. I was also thinking to make a repository for SwinjectStoryboard. However, Apple introduced their own Swift Package Manager with source layouts for modules. Now I think it's good to follow their source layout convention like this:
Swinject repository root
  |- Sources
  |   |- Core
  |   |- Assembly
  |   |- SwinjectStoryboard (if possible because it contains Objective-C code)
  |- Tests
      |- Core
      |- Assembly
      |- SwinjectStoryboard (if possible because it contains Objective-C code)

What do you think about the source layouts in a single repository or multiple repositories to add the assembly feature?

Good question. Be it that SPM is still so new (doesn't even support iOS, watchOS, or tvOS yet...) I believe we will see many improvements to its API over the next year. With that said the Source layout structure is probably a better idea compared to separate repos at this time. This would also make supporting CocoaPods very easy with subspecs (not so much for Carthage as now you have to maintain a separate build target for each sub-directory for each platform, but eh what can ya do)
Likely the submodules would need better naming to prevent conflicts as Core and Assembly are very generic. So would probably need to prefix Swinject to each submodule since you cannot specify this in the Package definition: SwinjectCore, SwinjectAssembly etc.. This is obviously very verbose but looks like a necessary requirement for SPM in its current state.
re: containing Objc code
This too I am very curious to see how this gets handled by Apple/Community. While Swift is awesome, many applications require Objc code, however I don't see SPM supporting Objc ever. Maybe there will be some plugin that will support xcodebuild to support Objc but who knows.

Thanks Mike. now I'm confident to go with the single repo. I'm going to start renaming the source and test directories to try SPM. I won't make submodule directories for now to see more new information or discovery about SPM.
You can implement the assembly feature without modifying the existing code, can't you? Just to prepare the submodule layout in the future. I think, even if something should be added to Container, it can be implemented in a new file with an extension to Container.
I am curious to see the Objc things too. We should watch. Another curiosity is Apple has decided to implement Foundation in Swift. (Core)Foundation was implemented in C with toll free bridge to Objective-C. Probably UIKit will replace its dependency on CoreFoundation to Swift Foundation.

@yoichitgy Yea the modular concept I am proposing will not required any changes to the existing structure. :+1:
I will go ahead with the proposal and submit a feature branch. We can discuss merge approaches when the time comes :smiley:

@mowens I added milestones to release the version 1.0.0 since we decided to manage Swinject in the single repo.
https://github.com/Swinject/Swinject/milestones

v1.0.0-beta.3: Planned for Issue #38 (a small breaking change). If you have an opinion to #38, it's welcome.
v1.0.0: Just wait for a week after the small breaking change to see no one complains.

The assembly feature can be included in v1.0.0-beta.3 or v1.1.0 when you finish the implementation😃

Implemented by PR #39.


bump fernet/fernet-go 9eac43b88a5efb8651d24de9b68e87567e029736

full diff: https://github.com/fernet/fernet-go/compare/1b2437bc582b3cfbb341ee5a29f8ef5b42912ff2...9eac43b88a5efb8651d24de9b68e87567e029736

fernet/fernet-go#14 verify should only check ttl if > 0

ping @cyli @wk8 PTAL
@cyli I saw you were on the discussion in https://github.com/fernet/fernet-go/pull/14 and running into this bug; should we cherry-pick this into the release branches?

failing on TestUpdaterRollback, which is flaky; https://github.com/docker/swarmkit/issues/2559 / https://github.com/docker/swarmkit/pull/2728


migrating to Node 20

Podman Desktop has migrated to Node 20 see https://github.com/containers/podman-desktop/pull/6128
Should we also migrate ?

cc @jeffmaury


Message-Editor subject changed event -> terrible performance when lots of folders

Description

Message-editor performance is terribly bad when mailbox has many folders (>50)
Folders object contain HATEOAS links for actions.
Each link is (>150 chars long), there are (as of now) 10 links per folder. (50210*150 ~= 100 KB)

Possible actions

Store state using Web worker -> #178
Persistence of state in IndexedDB should be debounced -> #179
Complete folders only stored in folders.explodedItems
Remove links from folders

-"Remove links from folders"
Best way

Good performance after all actions have been tackled


<EMAIL_ADDRESS>throws error "this.options.getBotUserByTeam is not a function"

Botkit version: 4.0.1
botbuilder-adapter-slack: 1.0.2
Messaging Platform: Slack
Node version: v10.15.1
Os: macOS 10.13.6
Any other relevant information:
I am starting botkit server on first incoming request and i am using botToken for initializing  SlackAdapter.

const adapter = new SlackAdapter({       verificationToken: verification_token,       botToken: bot_access_token   });
In constructor of the SlackAdapter it is calling this.slack.auth.test() for populating this.identity.
As this is external call, it takes time to populate this.identity. But as I am immediately passing incoming request to processActivity function, it fails at function getBotUserByTeam with error "this.options.getBotUserByTeam is not a function".
As  this.identity is yet null, code tries to call this.options.getBotUserByTeam which is undefined. There should be some way to know if SlackAdaptor is initialized completely or not.
I am calling processActivity function  in ready function of botkit. But this ready function is called before call to this.slack.auth.test()  is complete.
So to fix the problem SlackAdaptor should notify botkit that it is ready to process incoming requests and botkit should execut ready function after Adaptor is completely initialized.

Interesting! Thank you for this bug report.

For now there is not a great way to solve this. If you are still experiencing a problem, I would introduce a short delay when your bot boots up before calling the adapter methods.


TimeBar's color

Describe your problem here.
I need help in the conversion of a 6.3 to 7.3 lua mod, i need to change the healthBar's color.
setProperty('timeBar.color', getColorFromHex('D416E3')) doesn't work, as it changes the bg of the bar too.
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No response

It's setTimeBarColors('[hex code for foreground]', '[hex code for background, or just 000000 if you wanna keep it black]')

Thanks @Draconic-Hybrid , it worked
Btw if anyone is curious im doing too slow d-sides


Save agent activities to the database

Summary
Add functionality to track and store agent execution times in the database.
Purpose

For Giselle: Enable accurate calculation of billable agent execution time
For users: Provide transparency into agent usage and associated costs within current billing cycle

Changes

Add new agent_activities table with columns:

agent_db_id (references agents table)
started_at (timestamp)
ended_at (timestamp)
aggregated_execution_time_ms (tracks total execution time including parallel tasks)

Implement database operations for activity tracking
Add cascade delete constraint to maintain referential integrity

[!Note]

aggregated_execution_time_ms accounts for parallel task execution times
Foreign key constraint ensures cleanup of related activities when an agent is deleted

TODO

[x] Run migrate on Preview
[ ] Run migrate on Production

@toyamarinyon

We are planning to change the current design of agent creation and execution, and are planning to introduce the new concept of Execution.

I understand.
I'll handle the saving record updates in a separate PR to align with the new concept. 👍

@shige @toyamarinyon
I've pushed a fix in commit 934bb73
Previously, the "✨ Run" button click wasn't updating the UI because the await operation was blocking the streamableValue return value.
The issue has been verified as resolved in the Preview environment.

@shige
Could you run migrate and deploy to Production, please?

@satococoa I did it! 🚀


Create iad Erfurt

@gagik-shah I am sorry, I have to close the request without merging, because this organization is a training center, not a college, nor a university. Please ensure that you are familiar with this repository rules located at the bottom of this page.
Your request is also has an incorrect filename. If your domain is iad.de, the filename has to be lib/domains/de/iad.txt.
If I am mistaken regarding your school, and it has at least one year-long IT-related course, please make a new request with correct filename, and the comment, which contains the following:

the school official website URL, if different from the domain you are submitting
an URL of a page on the official website where an IT-related long-term (>1 year) course is offered by the school
an URL of a page or another proof (.pdf or a screenshot are OK) showing that the school recognizes the domain which you are submitting as an official email domain for the students.

Thank you!


[ITV] ERROR: Unable to extract params ('Unable to extract %s' % _name)

Checklist

[x] I'm reporting a broken site support
[x] I've verified that I'm running youtube-dl version 2021.12.17
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar issues including closed ones

Verbose log

python3 -m youtube_dl --user-agent "Mozilla/5.0" -f mp4/best http://www.itv.com/watch/the-chase/1a7842/1a7842a1903 --hls-prefer-ffmpeg --verbose
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--user-agent', 'Mozilla/5.0', '-f', 'mp4/best', 'http://www.itv.com/watch/the-chase/1a7842/1a7842a1903', '--hls-prefer-ffmpeg', '--verbose']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2021.12.17
[debug] Git HEAD: f24bc9272
[debug] Python 3.11.4 (CPython arm64 64bit) - macOS-14.0-arm64-arm-64bit - OpenSSL 3.1.1 30 May 2023
[debug] exe versions: ffmpeg 6.0, ffprobe 6.0, rtmpdump 2.4
[debug] Proxy map: {}
[ITV] 1a7842a1903: Downloading webpage
ERROR: Unable to extract params; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/Users/Orca/Downloads/youtube-dl/youtube_dl/YoutubeDL.py", line 829, in wrapper
    return func(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/Orca/Downloads/youtube-dl/youtube_dl/YoutubeDL.py", line 850, in __extract_info
    ie_result = ie.extract(url)
                ^^^^^^^^^^^^^^^
  File "/Users/Orca/Downloads/youtube-dl/youtube_dl/extractor/common.py", line 535, in extract
    ie_result = self._real_extract(url)
                ^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/Orca/Downloads/youtube-dl/youtube_dl/extractor/itv.py", line 193, in _real_extract
    params = extract_attributes(self._search_regex(
                                ^^^^^^^^^^^^^^^^^^^
  File "/Users/Orca/Downloads/youtube-dl/youtube_dl/extractor/common.py", line 1013, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
youtube_dl.utils.RegexNotFoundError: Unable to extract params; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Description

I'm trying to download videos from ITV, however, each time I try (regardless of the video), I get an "unable to extract params" error. I am using the latest master. I can watch any of the shows through the browser without issue.
Only similar issue I've been able to find is #22638 which does not give a fix

My error ("unable to extract uploader id") may be related and caused by the same RegexNotFoundError('Unable to extract %s' % _name).
Enter query: Hello Searching Hello YQHsXMglC9A ffplay version 4.4.2-0ubuntu<IP_ADDRESS> Copyright (c) 2003-2021 the FFmpeg developers   built with gcc 11 (Ubuntu 11.2.0-19ubuntu1)   configuration: --prefix=/usr --extra-version=0ubuntu<IP_ADDRESS> --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-pocketsphinx --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared   libavutil      56. 70.100 / 56. 70.100   libavcodec     58.134.100 / 58.134.100   libavformat    58. 76.100 / 58. 76.100   libavdevice    58. 13.100 / 58. 13.100   libavfilter     7.110.100 /  7.110.100   libswscale      5.  9.100 /  5.  9.100   libswresample   3.  9.100 /  3.  9.100   libpostproc    55.  9.100 / 55.  9.100 [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['--verbose', '-f', 'best', '-o', '-', 'https://www.youtube.com/watch?v=YQHsXMglC9A'] [debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8 [debug] youtube-dl version 2021.12.17 [debug] Python version 3.10.6 (CPython) - Linux-<IP_ADDRESS>-microsoft-standard-WSL2-x86_64-with-glibc2.35 [debug] exe versions: ffmpeg 4.4.2, ffprobe 4.4.2, rtmpdump 2.4 [debug] Proxy map: {} [youtube] YQHsXMglC9A: Downloading webpage    0KB sq=    0B f=0/0    ERROR: Unable to extract uploader id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. Traceback (most recent call last):   File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 815, in wrapper     return func(self, *args, **kwargs)   File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 836, in __extract_info     ie_result = ie.extract(url)   File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 534, in extract     ie_result = self._real_extract(url)   File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py", line 1794, in _real_extract     'uploader_id': self._search_regex(r'/(?:channel|user)/([^/?&#]+)', owner_profile_url, 'uploader id') if owner_profile_url else None,   File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 1012, in _search_regex     raise RegexNotFoundError('Unable to extract %s' % _name) youtube_dl.utils.RegexNotFoundError: Unable to extract uploader id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

@xaoscience, no: read #30839 as asked.
#22638 hasn't got anything to do with ITV. Unfortunately the ITV(x) page structure has changed. The desired playlist URL can now be found with this:
--- old/youtube_dl/extractor/itv.py
+++ new/youtube_dl/extractor/itv.py
@@ -189,14 +189,19 @@

         webpage = self._download_webpage(url, video_id)

-        # now quite different params!
-        params = extract_attributes(self._search_regex(
-            r'''(<[^>]+\b(?:class|data-testid)\s*=\s*("|')genie-container\2[^>]*>)''',
-            webpage, 'params'))
-
-        ios_playlist_url = traverse_obj(
-            params, 'data-video-id', 'data-video-playlist',
-            get_all=False, expected_type=url_or_none)
+        ios_playlist_url = url_or_none(self._search_regex(
+            r'''\bplaylistUrl['"]\s*:\s*(?P<q>"|')(?P<url>https?://magni\.itv\.com/playlist/(?:(?!(?=q)).)+)''',
+            webpage, 'playlist URL', group='url', fatal=False))
+
+        if not ios_playlist_url:
+            # legacy: does it ever happen?
+            params = extract_attributes(self._search_regex(
+                r'''(<[^>]+\b(?:class|data-testid)\s*=\s*("|')genie-container\2[^>]*>)''',
+                webpage, 'params'))
+
+            ios_playlist_url = traverse_obj(
+                params, 'data-video-id', 'data-video-playlist',
+                get_all=False, expected_type=url_or_none)

         headers = self.geo_verification_headers()
         headers.update({

Again unfortunately, then we get 404
...
[ITV] 1a7842a1903: Downloading webpage
[ITV] 1a7842a1903: Downloading JSON metadata
ERROR: Unable to download JSON metadata: HTTP Error 404: Not Found ...

when fetching the data with the URL.
Perhaps @Vangelis66 can advise on how, or if at all, the POST to the playlist URL can be modified so as to return valid data.

I ran into this yesterday.  I believe the issue is the variantAvailability parameter.  Currently it is sending:
'variantAvailability': {
                    'player': 'hls',
                    'featureset': {
                        'min': ['hls', 'aes', 'outband-webvtt'],
                        'max': ['hls', 'aes', 'outband-webvtt']
                    },
                    'platformTag': 'mobile'
                }

This returns 404 and the following message:
{
	"Message": "something needed to service this request was missing",
	"TransactionId": "oas-xxx"
}

The desktop web client sends:
  "variantAvailability": {
    "player": "hls",
    "featureset": {
      "min": [
        "mpeg-dash",
        "widevine",
        "outband-webvtt",
        "hd",
        "single-track"
      ],
      "max": [
        "mpeg-dash",
        "widevine",
        "outband-webvtt",
        "hd",
        "single-track"
      ]
    },
    "platformTag": "dotcom"
  }

But the response from this doesn't allow the download to work.
FWIW I think this 404 might only apply to newer shows.  It fails for
https://www.itv.com/watch/tour-de-france/34067/1a7000a0353
But the original POST params work for the built in test case:
https://www.itv.com/watch/vera/1a7314/1a7314a0014

Similar on some YouTube URLs, but as a WARNING and it is still possible to download the file.
❯ youtube-dl --verbose -w -o "Day4.mp4" https://youtu.be/nlGIBcMc-oo
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', '-w', '-o', 'Day4.mp4', 'https://youtu.be/nlGIBcMc-oo']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2021.12.17
[debug] Python version 3.10.6 (CPython) - Linux-5.19.0-46-generic-x86_64-with-glibc2.35
[debug] exe versions: ffmpeg 4.4.2, ffprobe 4.4.2
[debug] Proxy map: {}
[youtube] nlGIBcMc-oo: Downloading webpage
[youtube] nlGIBcMc-oo: Downloading player 1dda5629
WARNING: [youtube] Unable to decode n-parameter: download likely to be throttled (Unable to extract Initial JS player n function alias (Wsa[0]); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl/extractor/youtube.py", line 1668, in _n_descramble
    self._player_cache[player_id] = self._extract_n_function(video_id, player_url)
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl/extractor/youtube.py", line 1640, in _extract_n_function
    funcname = self._extract_n_function_name(jscode)
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl/extractor/youtube.py", line 1623, in _extract_n_function_name
    real_nfunc = self._search_regex(
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl/extractor/common.py", line 1013, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
youtube_dl.utils.RegexNotFoundError: Unable to extract Initial JS player n function alias (Wsa[0]); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
)
[debug] Default format spec: bestvideo+bestaudio/best
[debug] Invoking downloader on 'https://rr2---sn-oxunxg8pjvn-jbgs.googlevideo.com/videoplayback?expire=1688755497&ei=yQioZMvDDcyM5gTQkY7IBw&ip=<IP_ADDRESS>&id=o-AN1CqedAxlpevC41ieTVpR0EAIOiR6_NeT3NEVmUJW8n&itag=137&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278&source=youtube&requiressl=yes&mh=Nh&mm=31%2C29&mn=sn-oxunxg8pjvn-jbgs%2Csn-bg0eznsk&ms=au%2Crdu&mv=m&mvi=2&pl=21&initcwndbps=1128750&spc=Ul2Sq6rib7rdlS1A10ohPTnKYyfvUXYvx0tyWRZK_w&vprv=1&svpuc=1&mime=video%2Fmp4&ns=pb-C5sBpt8XZ1WsWV8bOb7EO&gir=yes&clen=915079030&dur=6916.966&lmt=1686771608585056&mt=1688733654&fvip=5&keepalive=yes&fexp=24007246%2C24362685%2C51000023&c=WEB&txp=5432434&n=gZvM5UW5G7a5PAEo&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cns%2Cgir%2Cclen%2Cdur%2Clmt&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRAIgYj1e5Y1PfcQklLfJj9440Hj_zDGNfbCakywIt72SwmgCIDjZ7YtBvpa2Ud0jPML8koPfGQhw01XebMZ8vev7UyEV&sig=AOq0QJ8wRQIhAIH9K5Qo_MfCVtz9_AH-F2dIdRCvIj9VJDQOZ7au_cVLAiAkDRRnrb2uZbIOQUW6IlzHSVdccfa9DeH9T9tf1CoJ1g=='
[dashsegments] Total fragments: 88
[download] Destination: Day4.f137.mp4
[download]   1.1% of ~880.00MiB at 72.49KiB/s ETA 03:24:58

@iskigow, unrelated: you need to update from the master code; see #32292 etc.

I ran into this yesterday. I believe the issue is the variantAvailability parameter. ...

The desktop client is tied into the DRM stuff. We pretend to be an old mobile, hence 'platformTag': 'mobile'. Maybe the 404 response is indicating that now there are no media links matching the featureset that we want.

@iskigow, unrelated: you need to update from the master code; see #32292 etc.

I'm using the master code, but I will update, rebuild and test again. Thanks.

are these methods still valid? from my testing DRM is required now:
10:25:04 INFO GET URL="https://content-inventory.prd.oasvc.itv.com/discovery?query=%7B+titles%28filter%3A+%7B+legacyId%3A+%221%2F7314%2F0014%22+%7D%29+%7B+...+on+Episode+%7B+seriesNumber+episodeNumber+%7D+...+on+Film+%7B+productionYear+%7D+brand+%7B+title+%7D+latestAvailableVersion+%7B+playlistUrl+%7D+title+%7D+%7D"
10:25:04 INFO POST URL=https://magni.itv.com/playlist/itvonline/ITV/1_7314_0014.003
10:25:05 INFO GET URL="https://itvpnpdotcom.blue.content.itv.com/1-7314-0014-003/34/2/VAR028-HD-s/1-7314-0014-003_34_2_VAR028-HD-s.ism/.mpd?filter=%28%28type%3D%3D%22video%22%26%26DisplayHeight%3C%3D720%29%7C%7C%28type%21%3D%22video%22%29%29&hdnea=st%3D1730042690~exp%3D1730064290~acl%3D/1-7314-0014-003/%2A~hmac%3D3d7081560064290b3fdb25e37093456d4308ca55f8da76051004fd88747b0555"
10:25:06 INFO GET URL="https://itvpnpdotcom.blue.content.itv.com/1-7314-0014-003/34/2/VAR028-HD-s/1-7314-0014-003_34_2_VAR028-HD-s.ism/dash/1-7314-0014-003_34_2_VAR028-HD-s-video=2000536.dash"
10:25:06 INFO POST URL="https://itvpnp.live.ott.irdeto.com/Widevine/getlicense?AccountId=itvpnp"
10:25:06 INFO CDM PSSH=CAESEIa5o8mmj0Pxh1+Z4TU9NlYiEjEtNzMxNC0wMDE0LTAwM18zNDgB key="LkR2HiMp4wEXKLZuA0sBZw=="
10:25:08 INFO 0.23 % size="2.67 megabyte" rate="2.51 megabyte/s"

As above, there used to be an edge case that would cause non-DRM low-res media to be served but that stopped working. Obvs if anyone who can spend time researching the issue comes up with a new work-around it can be implemented, but I'm not optimistic.

I would recommend closing issue - I just finished the first public implementation of ITVX and from what I can tell DRM is required

I would recommend closing issue - I just finished the first public implementation of ITVX and from what I can tell DRM is required
@PacoH

... For those still wanting some (detailed) answers, a recap:
Nov 2022 saw ITV Hub turn into itvX;
During the ITV Hub era, yt-dl would pretend to be an old iPhone to grab 540p HLSe streams (HLSe = AES-128 encrypted HLS, a form of "soft" DRM); desktop clients would get cenc (full-blown-DRM) MPEG-DASH streams.
itvX will since deliver Apple FairPlay (full-blown-DRM) HLS streams to "old iPhones"; together with the overall site changes, yt-dl became totally kaput for itvX ...
A "hack" was discovered to forcefully request/extort the decommissioned (but still extant) HLSe mobile streams for use with yt-dl.
The "hack" was authored into Python code and merged into the master branch on Feb 4 2023.
itvX gradually re-broke the extractor in the month of July 2023, but the "hack" itself was finally defeated on July 26 2023: HLSe streams for programmes could no longer be "extorted" (the necessary infra shut down?), thus putting a definite end to the itvX yt-dl extractor (since yt-dl won't ever "touch" full-blown DRM) :cry: ...
References:
https://github.com/yt-dlp/yt-dlp/issues/5570
https://github.com/yt-dlp/yt-dlp/issues/10937

but I'm not optimistic

...same here :wink: ...

I would recommend closing issue

I tend to agree, so as not to harbour false hopes...
It has been a nice ride for many years...

note as my code block above shows its still very possible to download from ITVX, just not with YouTube-DL/YT-DLP because of policy reasons

Happy to re-open if anyone offers a solution, and meanwhile STVPlayerIE still appears to work (UK-only, I expect) for the many ITV shows that are also available on STV. North Britain FTW.


Insecure password in POST request

Describe the Bug

Steps to Reproduce
Goto: https://demo.bookstackapp.com/login
Enter login & password
Click "Вход"
Expected Behaviour
Hashed or crypted password
Screenshots or Additional Context
No response
Browser Details
Any
Exact BookStack Version
22.04.2 (may be)
PHP Version
No response
Hosting Environment
Demo

@KarelWintersky You may also need to report this one to google, since their login does the same.
Passwords are hashed in storage in BookStack. Hashing/encrypting client side doesn't really add much security, just adds complexity. Sure, it may slightly help in non-HTTPS cases, but it still won't protect access to the BookStack account and those cases are already open to a wider array of security concerns.

You may also need to report this one to google,

appealing to the errors of a third-party resource cannot be an excuse

@KarelWintersky Sure, It was a joke though,  hence why I justified our existing methods in my comment above.
Happy to hear why we're insecure though if you believe this to be a legitimate vulnerability.


Add support for special folders (known folders) via a separate provider / namespace

The filesystem has a number of special folders (a.k.a. known folders): usually preexisting folders that have special meaning to the OS.
It would be convenient to be able to target them in the abstract - both for convenience and for platform abstraction - similar to what .NET provides; e.g.:
# E.g., on Windows:
PS> [Environment]::GetFolderPath('Desktop')
C:\Users\jdoe\Desktop

'Desktop' translates to an enum value from the [Environment+SpecialFolder] enumeration.
Supporting these enum values via a new -SpecialFolder (alias -sf) parameter natively in PowerShell would be handy:
(Example removed.)
Update:  A better way to surface this functionality is via a sf: or SpecialFolder: drive, which would enable the following syntax:
Set-Location $sf:Desktop  # wishful thinking: changes to, e.g., C:\Users\jdoe\Desktop
$sf:Desktop  # wishful thinking; returns that path; short for: (Get-Item sf:Desktop).Value

Environment data
Written as of:
PowerShell Core v6.1.0-preview.2

Seems using a prefix for special folders is better UX then parameter. We can not use ~, maybe ~~MyPictures?

@iSazonov:
I know that -SpecialFolder (or -SpecialDirectory, given that PowerShell uses the term directory) is lengthy, but the -sf alias would mitigate that.
~~MyPictures is, at least hypothetically, a breaking change, because nothing stops you from creating a folder literally named ~~MyPictures.
(Note that POSIX-like shells support ~<username> as a shortcut for referring to a different user's home folder (but only if used unquoted), but it's an obscure feature that I don't think is worth adopting in PowerShell.)
More generally, the meaning of ~ is relative to the provider underlying the current location and therefore generally not suitable to unconditionally refer to a filesystem location.
A more PowerShell-like solution would be to:

Implement a SpecialFolder drive provider that exposes, say, drive sf:,

which would then allow you to use namespace notation to access its items; e.g.,
Set-Location $sf:MyPictures

Also, cd ~\pictures is less to type.  Ditto with cd ~\desktop.  With tab completion there is even less to type cd ~\de<tab>.

@rkeithhill:
Yes, but that (a) already works and (b) only if the current location is a filesystem location.
While in a filesystem location, ~ is a convenient shortcut (that, unfortunately, is not fully semantically equivalent with (unquoted) ~ in POSIX-like shells such as bash due to its current-location sensitivity).
The stated limitation aside, you can therefore think of ~ as the one special-folder shorthand in PowerShell that is already available, and for other special folders that happen to be in the home folder's subtree, something like ~/Desktop works well.
However, just like ~ is a useful abstraction - it may refer to, say, C:\Users\jdoe, /home/jdoe, or /Users/jdoe, for instance - having abstractions for other well-known folders is equally useful, and that's where the special folders come in.
For instance, the ApplicationData special folder is something like C:\Users\jdoe\AppData\Roaming on Windows, and $env:HOME/.config on Unix-like platforms.
Even ~ has its conceptual limitations: as @iSazonov  pointed out in https://github.com/PowerShell/PowerShell/issues/6791#issuecomment-393465147, you can think of ~ on Unix corresponding to ~\Documents on Windows, given that Windows discourages creating user content directly in the profile folder;
Unlike, ~, the MyDocuments (alias: Personal) special folder provides exactly this abstraction: it returns  the equivalent of ~ ($HOME) on Unix, and ~/Documents on Windows.
The ~ shorthand doesn't scale well: something like ~~MyDocuments and ~MyDocuments, as stated, is a breaking change, but, perhaps more importantly, it would be self-contradictory in the case of user-independent folders, such as CommonApplicationData (which is C:\ProgramData on Windows, and /usr/share on Unix).

but that (a) already works

Yup, I'm questioning the value of the proposed feature.

the ApplicationData special folder is something like C:\Users\jdoe\AppData\Roaming on Windows, and $env:HOME/.config on Unix-like platforms.

Trying to map Windows oriented locations to *nix doesn't sound like a good idea to me.

~~MyPictures is, at least hypothetically, a breaking change, because nothing stops you from creating a folder literally named ~~MyPictures.

Why stops? We can use escaping and LiteralPath.
Seems on Unix the ~ is valid name too. And all the other options too.
I think we could enhance ~ and use ~CommonApplicationData.

Trying to map Windows oriented locations to *nix doesn't sound like a good idea to me.

This has already been implemented in CoreFX and PowerShell Core.

This has already been implemented in CoreFX and PowerShell Core.

Well, except that a lot of those enumeration values don't make sense on Linux/macOS.  As such, most of those enumerations result in empty string results:
17:16ms>  $ht = @{}; [Enum]::GetValues('System.Environment+SpecialFolder') | % { $ht[$_] = [Environment]::GetFolderPath($_) }; $ht

Name                           Value
----                           -----
CDBurning
CommonOemLinks
LocalizedResources
Resources
CommonVideos
CommonPictures
CommonMusic
AdminTools
CommonAdminTools
CommonDocuments
CommonTemplates
CommonProgramFilesX86
CommonProgramFiles
ProgramFilesX86
SystemX86
UserProfile                    /home/hillr
MyPictures
ProgramFiles
System
Windows
CommonApplicationData          /usr/share
History
Cookies
InternetCache
LocalApplicationData           /home/hillr/.local/share
PrinterShortcuts
ApplicationData                /home/hillr/.config
CommonDesktopDirectory
CommonStartup
CommonPrograms
CommonStartMenu
Templates
Fonts
NetworkShortcuts
MyComputer
DesktopDirectory
MyVideos
MyMusic
StartMenu
SendTo
Recent
Startup
Favorites
MyDocuments                    /home/hillr
Programs
Desktop

Consequently, this would be a Windows-centric feature IMO.

@BrucePay:

Indeed, and since it hasn't really come up much in over a decade of Windows PowerShell (it's been proposed but there wasn't much interest)

On Windows, you could typically get away with (semi-)hard-coded paths.
In a cross-platform world, that's no longer an option, so the special-folder abstractions become more valuable.

In what way is it not fully semantically equivalent? Do you mean the fact that it takes you to the home location on the current drive?

Yes: If you come from a Unix background and expect cd ~\Desktop to always take you to $HOME\Desktop, you'll be surprised:
PS> Set-Location Alias:
PS Alias:/> cd ~\Desktop  # boom
cd : Home location for this provider is not set. To set the home location, call "(get-psprovider 'Alias').Home = 'path'".
...

These days, most Linux distros as well as MacOS use the same folder structure as Windows, with Documents directory, Pictures, Movies, etc. So ~ in *sh and ~ in PowerShell are pretty much equivalent.

Fortunately, yes (though CoreFx has chosen to consider just ~ the equivalent of Windows ~/Documents via [Environment]::GetFolderPath('MyDocuments'), but that wouldn't affect explicit use of ~/Documents).
However, as implied by the above, scripts should only ever use $HOME, not ~ , in order to reliably refer to the user's home folder.

@iSazonov:

Why stops? We can use escaping and LiteralPath.

Unlike in POSIX-like shells, where the shell expands ~ only if unquoted, ~ in PowerShell is a literal path, and it is up to the target provider to interpret it; the following statements are all equivalent:
Set-Location ~    # implied -Path
Set-Location '~'  # ditto, with quoting
Set-Location -LiteralPath ~
Set-Location -LiteralPath '~'

I think the idea of a special PSDrive is a really good one

@mklement0

Yes: If you come from a Unix background and expect cd ~\Desktop to always take you to $HOME\Desktop, you'll be surprised:

Coming from a Unix/POSIX background, I'll admit that this was a decision I was not thrilled with. We have considered changing it a few times but did not. I wish we'd done it for 6.0.

Unlike in POSIX-like shells, where the shell expands ~

True. There is a difference in layers and responsibilities. The upside is this allows us to glob against things like processes without needing to quote.

On Windows, you could typically get away with (semi-)hard-coded paths.
In a cross-platform world, that's no longer an option, so the special-folder abstractions become more valuable.

The whole reason for special folders on Windows is because it wasn't possible to have hard-code paths. For example, it used to be recommended that you have your documents on a different drive than the system. This sort of thing necessitated redirection. Unix, on the other hand, has been pretty consistent with directory naming (/etc is always /etc). And the various distributions seem to have settled on more or less the same set of user directories.

Fortunately, yes (though CoreFx has chosen to consider just ~ the equivalent of Windows ~/Documents via [Environment]::GetFolderPath('MyDocuments', but that wouldn't affect explicit use of ~/Documents).

I didn't quite follow this. ~ processing is a PowerShell thing, not a Windows or CoreFX thing. At least I'm not aware of them doing anything with ~.
@iSazonov

We can not use ~, maybe ~~MyPictures?

Actually that's pretty much the proposal @JamesWTruher and I had way back in V1. ~/<directory> would have been relative to the home directory but ~documents, ~ApplicationData etc. would have been the special folders,  And something like ~ApplicationData/npm would be a special-folder relative path.  The nice thing with this approach is that you could allow user-defined short cuts e.g. ~src or ~test/scripts.

These days, most Linux distros as well as MacOS use the same folder structure as Windows, with Documents directory, Pictures, Movies, etc. So ~ in *sh and ~ in PowerShell are pretty much equivalent.

So I expect that CoreFX will map special folder name wider. Any ported music player can use "MyMusic" special folder on any platform.
Other thoughts about ~.

I don't like that it conflict with Unix ~user. Can we use another prefix?
If we look Windows applications like SCCM (system center configuration manager) or GPP (group policy preferences) they use internally %specialfolder% format.
CoreFX has Environment.ExpandEnvironmentVariables to expand environment variables and
Environment.GetFolderPath() to expand special folder names in paths.
Also in cmd.exe  dir %temp% works but not in PowerShell.
Do we want both expansions to work in PowerShell?

@BrucePay:

For example, it used to be recommended that you have your documents on a different drive than the system. This sort of thing necessitated redirection.

On a related not: It looks like what PowerShell reports as $HOME is %USERPROFILE%, which is typically, but not necessarily is the same as %HOMEDRIVE%%HOMEPATH%; the former is the roaming part of the user profile and the latter is where the user's personal files go.
If they do differ, something like ~/Desktop will not work as intended.
So, given that redirection (abstract locations whose machine-specific instantiation is obtained programmatically) is still a necessity in the Windows world, it doesn't even help that Linux distros have standardized locations such as ~/Desktop - for reliable operation you still need the redirection.

I didn't quite follow this. ~ processing is a PowerShell thing, not a Windows or CoreFX thing. At least I'm not aware of them doing anything with ~

I was using ~ merely as shorthand alias for $HOME (Unix) and %HOMEDRIVE%%HOMEPATH% in my example (I'll call both $HOME below).
I was trying to point out that if you ask the .NET API for the path to the user's documents -  [Environment]::GetFolderPath('MyDocuments'):

you get $HOME itself on Unix
you get $HOME\Documents on Windows

In other words: from the perspective of CoreFx, location $HOME/Documents -  even though it does exist on all platforms - is not considered equivalent across platforms.

To summarize:
The upshot:

Even Windows-only scripts benefit from using abstractions, because something like ~\Desktop or $HOME\Desktop doesn't always work.

Fully cross-platform scripts are limited to a relatively  small subset of the special folder.

More abstractions become available for scripts that target Windows + macOS, or Windows + Linux only.

Specifically,  here is the list of which special folders are defined on what platforms: (on Windows, where the feature :

Windows: Since the feature originated there, all special folders are defined.

Shared - defined on all platforms (note: Desktop and DesktopDir, though technically distinct, seem to refer to the same location in practice; the former is distinguished from the latter as being the "logical Desktop rather than the physical file system location" - not sure what that means).

ApplicationData
CommonApplicationData
Desktop
DesktopDirectory
LocalApplicationData
MyDocuments
MyMusic
MyPictures
UserProfile

additionally, unique to macOS (not also on Linux)

Favorites
Fonts
InternetCache
ProgramFiles
System

additionally, unique to Linux (not also on macOS)

MyVideos
Templates

Re syntax:

Can we use another prefix?
And something like ~ApplicationData/npm would be a special-folder relative path.

Generally, using a special symbol (prefix) - while conveniently concise - is arcane (something you'd expect from Perl, not from PowerShell), even though it builds on a well-known symbol in the Unix world.

Also, as stated, given the established meaning of ~ as the user's home folder, something like ~ProgramFiles - a user-independent location - is self-contradictory.
(The ~<username> syntax in shells such as bash is a more natural extension of ~, but is not widely used.)

Similarly, we should stay away from %specialfolder%, given that it looks like cmd.exe's environment variables, whereas PowerShell uses $env:<name> to surface environment variables.
By contrast, using namespace notation still allows for concision while using established PowerShell idioms; e.g.:
Set-Location $sf:Desktop  # tab-completion would work too

Implementing a provider just for this purpose may seem heavy-handed, but doing so is currently a prerequisite for namespace notation.
So, the wider question is: perhaps we should support defining namespaces in a more lightweight manner, without needing to implement a full-blown drive provider?

@mklement0 Thanks! I always like your analysis.
I like the idea. Only without $
Set-Location SpecialFolder:Desktop # full name
Set-Location sf:Desktop  # short name

the wider question is: perhaps we should support defining namespaces in a more lightweight manner, without needing to implement a full-blown drive provider?

Seems currently no - this will require the alteration of internal interfaces. We have a similar request for providers. Feel free tracking Issue for drives too.
However, we could implement this new drive even today :-) - we only need RFC. It was great if you did. Seems it will be very short.
Also I would not leave without attention my question about environment variables. They are often used in other shells. We should think about how to use them more easily in PowerShell.

Thanks, @iSazonov; similarly, I appreciate your tireless efforts and countless contributions.
On second thought, you're right: implementing a drive provider is the way to go, and the right solution is to make implementing one more "lightweight", i.e.: easier: #5789.
As for how that new drive's items must be accessed, let me start with environment variables, because how they are surfaced exemplifies how I think the special folders should be surfaced too:

Also I would not leave without attention my question about environment variables. They are often used in other shells. We should think about how to use them more easily in PowerShell.

I think that PowerShell's way of exposing environment variables works fine and is sufficient:

The env: drive enumerates all environment variables (e.g., (Get-Item Env:PATH).Value reports the value of environment variable PATH)

The generic namespace-notation feature therefore allows accessing these items using, e.g., $env:PATH; in other words: $<drive-name>:<item-name> is the concise (and presumably more efficient) equivalent of (Get-Item <drive-name>:<item-name>).Value)

Namespace notation makes for a concise, yet friendly notation that supports tab completion and even direct embedding in expandable strings (without the need for enclosing $(...)); e.g.: "PATH: $env:PATH"
It's a powerful concept, and even though use of the $env: namespace is widespread  - because it's the simplest way to access environment variables -  my sense is that not many people know how generic the underlying mechanism is.
If we implement a SpecialFolders drive provider and surface the special folders via a new drive named sf: (we could name it SpecialFolder:, but note that there's no concept of drive-name aliases, so from what I understand, if we wanted to support both sf: and SpecialFolder:, we'd have to define two drives), accessing it via namespace notation looks the way I proposed:
Set-Location $sf:Desktop

That would actually obviate the need to extend Get-Location, because Get-Item sf:Desktop would be sufficient - or simply $sf:Desktop by itself.
By contrast, the syntax you propose would break:
Set-Location sf:Desktop   # !! breaks, if sf: is a drive

This would attempt to navigate to the sf: drive's Desktop container, but Desktop isn't a container: it's a leaf-type item analogous to files in the filesystem provider.
(Similarly, Set-Location Env:PATH breaks, as would analogous call for all non-hierarchical providers that have just one level of invariably leaf-type items, namely: Alias:, Function:, Variable: - the only path you can navigate to on drives of such providers is the root location; e.g., Set-Location Env:.)

This may be related. I've installed PowerShell 6.1.2 and when I cd \Users\<user>\Desktop, I can't create a folder using mkdir test. I can with PowerShell 5.1.17763.124.
Has something changed?!

@Praful Please open new Issue with repo steps.

@mklement0 Is the discussion ready for PowerShell Committee review? Could you please summorize the discussion?

Thanks for the follow-up, @iSazonov: Yes, I think it's ready; to summarize, the proposal is:
To provide convenient cross-platform abstractions for well-known folders in a PowerShell-idiomatic manner, surface the functionality of [Environment]::GetFolderPath(), via namespace variable notation as $sf:<known-folder-name>, where <known-folder-name> is an Environment.SpecialFolder enum value - e.g., $sf:Desktop would be the equivalent of [environment]::GetFolderPath('Desktop')
Note: Not all well-known folders exist on all platforms - see the bottom section of this comment for details; if they don't, [Environment]::GetFolderPath() returns the empty string (e.g., [environment]::GetFolderPath('CDBurning') on macOS); we could mirror that practice.
To that end:

Implement a non-hierarchical, read-only provider that implements the IContentCmdletProvider interface and whose items are named for the Environment.SpecialFolder enumeration values and whose content is the value of passing their name to [Environment]::GetFolderPath()

Define a drive named sf for that provider.

As an optional extension to the proposal above:

Accept an additional enum value named, say, Temp, to return the platform-specific path to the folder for temporary files that surfaces the value of  [System.IO.Path]::GetTempPath(), PowerShell currently has no analog - see #4216; support for $sf:Temp would resolve that.

@SteveL-MSFT The issue is ready for reviewing by PowerShell committee.

@PowerShell/powershell-committee started discussing this but didn't reach a conclusion.  One proposal that came up is a folder under env: rather than a new PSDrive.  So it would look like env:/SpecialFolder/Fonts, for example.  Although SpecialFolders are not environment variables, they are folders that are part of the user's environment, so conceptually, it works.

I wouldn't recommend that. Requiring slash separators to access them means that accessing them as though they were variables (like you can with $env:TEMP) becomes cumbersome. Not everyone is aware of braced syntax for variables, after all, it's a bit of a niche thing.
It appears the intent here is to make it easier to access these folders, and I don't think burying it in a special subtree of Env: makes any sense. Everything else in there is single-level, a flat one-dimensional array of strings, effectively... Unless there are further plans to abstract that drive to increase usability and make it more robust as a whole, I very much doubt that creating a special case here will help anything.

 To me (and I'd expect most of the community as well) $env and the Environment provider == "environment variable". According to @JamesWTruher, $env was really supposed to contain any useful information about the environment, more akin to [System.Environment] which would then rightfully include the special folders.
I argued that the original intent is likely not clear to users and that it would make sense to distinguish from $env in some way, and was more in favor of something like $sf, but that means we need a PSDrive, or it'll be an automatic variable. As @mklement0 argued above, we also felt that a PSDrive would be a little heavy-handed, and it's especially wonky to me because these aren't settable items. You're just accessing some read-only values from the system.
If it's an automatic variable, then we have to special-case it as one that somehow parses :foo. From an "I can see what's going on under the hood" perspective, this is wonky too. I know we have lots of magic in PowerShell, but we're doing our best not to add more (cue people calling me out for wanting magic in the PSModulePath RFC :) )
So that's why we landed in a place where we wanted to move towards the original intent: to move more information about the environment into the Environment provider. In the future, we could want more there beyond special folders, and it would make sense to set a precedent for that now so we're not arguing for more read-only providers in the future.
Additionally, I'd argue that this is feature is way more cross-platform abstraction than it is about ease of typing. There's all sorts of ways you can alias folders you care about to shorthand for your interactive sessions, but this is more about providing a way for PS users to natively abstract these special folders (whether it's cross-platform the ones that happen to have values defined on Linux, as well as to mitigate potentially weird folder locations within pure Windows environments).
Out of curiosity, is there any reason no one raised a Get-SpecialFolder cmdlet? Are there some parse vs. runtime concerns that crop up if we go that route? (Upon which everyone could just alias it to gsf or something so that e.g. (gsf TEMP) just works.)

Hm. A cmdlet has a bit more overhead than a provider or some such, but otherwise I see nothing wrong with it.
I think I can understand that perspective with the Environment PSProvider. The biggest thing at the moment is that it doesn't currently appear to support anything like a container node -- trying to create Env:\MyThing\Var at the moment (from memory, at least) creates just a single item named MyThing\Var, doesn't it?
I have no qualm with changing that and making it work, though. 😄

To me (and I'd expect most of the community as well) $env and the Environment provider == "environment variable".

How resolve this?

@PowerShell/powershell-committee reviewed this, we would also be ok with cmdlets for Get-SpecialFolder

@PowerShell/powershell-committee reviewed this, we would also be ok with cmdlets for Get-SpecialFolder

IMO the provider approach (i.e. sf:MyPictures) would make for less typing.

This would attempt to navigate to the sf: drive's Desktop container, but Desktop isn't a container: it's a leaf-type item analogous to files in the filesystem provider.

TEMP: is a container now, why can’t sf:Desktop be?

I phrased that poorly:
The idea is for $sf:Desktop (which is the implicit equivalent of Get-Content sf:Desktop - not Get-Item sf:Desktop) to directly return a native path string that represents the platform-specific Desktop folder, so that you can use it directly in arguments; e.g., [IO.File]::CreateText("$sf:Desktop/foo.txt")
This behavior is the primary utility of the $sf:Desktop syntax, given that a mere provider-path string such as sf:Desktop by itself is only meaningful to PowerShell's provider cmdlets (unlike native file-system paths such as C:\Users\Desktop).
So my thinking was that the drive's items do not themselves need to represent directory (container) items, and the only practical need to explicitly call provider cmdlets would be for discovery: e.g., Get-ChildItem sf: or Get-Item sf:*music*
I suppose we could do both, and also treat drive sf: like any other PS-drive-based file-system drive, but there's a conceptual problem:

What file-system location should sf:/ - the root of all special folders - represent? There is no natural candidate, yet we don't want to disallow Set-Location sf:/ altogether, given that it works with other providers (e.g., Set-Location alias:/ works just fine); if location sf:/ doesn't represent an actual file-system item - just as alias:/ doesn't -  the problem doesn't arise.

Also, $PWD will then report sf:Desktop rather than C:\Users\jdoe\Desktop, for instance - as with custom PS drives.

What file system location does My Computer represent?  You can explore it, you can link to it but you cannot pass it to an application that expects a directory.  It is the same situation.

It is not, because My Computer (This PC) is a concept of the Windows GUI shell's namespace, and its abstract locations aren't directly usable in PowerShell, so the problem doesn't currently exist - we would be introducing it to PowerShell.
(If you try launching a PowerShell console from File Explorer from an abstract location such as This PC, you'll get set-location : Cannot find path '::{20D04FE0-3AEA-1069-A2D8-08002B30309D}' because it does not exist., and, similarly, you can't query its children with Get-ChildItem.)
That said, I'd be fine with, say, mapping location sf:/ to the root of the system drive (/ on Unix, and typically C:\ on Windows).
Again: What matters at the end of the day is that $sf:Desktop directly expands to the platform-specific, native file-system path representing the abstract location.

In keeping with existing providers, it would make the most sense if SF: itself mapped to an abstract location from where you can call Get-ChildItem and get a list of special folders and their locations:
PS> Get-ChildItem sf:

Name          Location
----          --------
Desktop       C:\Users\currentUser\Desktop
My Documents  C:\Users\currentUser\My Documents

Yes, @vexx32, but we would get that behavior even if the items themselves do not map directly to file-system locations; as I said above:

the drive's items do not themselves need to represent directory (container) items, and the only practical need to explicitly call provider cmdlets would be for discovery: e.g., Get-ChildItem sf: or Get-Item sf:*music*

This would work just like Get-ChildItem alias:/, for the alias: drive, which also does not map to file-system locations.
To summarize:

What's important is that namespace variable notation - e.g., $sf:Desktop - directly expands to the platform-specific, native file-system path underlying the abstract location.

I'm personally fine with also making the drive navigable as a special file-system provider (rather than a provider that returns path strings), but I think that is far less important:

If we don't make sf: a special file-system provider, not much is lost: instead of Set-Location sf:Desktop you'd then have to use Set-Location $sf:Desktop (analogously for Get-Item and Get-ChildItem), which doesn't strike me as a hardship - though there may be potential for confusion.

If we do do that:

We need to decide how to handle Set-Location sf:/, which all providers currently support.

Either: Prevent navigating directly to sf:/, with a meaningful error message.
Or: Map sf:/ to an ultimnately arbitrary file-system locations, such as the root of the system drive.

Either way, we need to be mindful that after, say, Set-Location sf:Desktop, $PWD would stringify as 'sf:/Desktop', which you cannot  directly use (to compose paths with) in calls that expect native file-system paths. (This applies to custom file-system PS drives equally, but creating those is a deliberate act, whereas in this case users may not expect this behavior; $PWD.ProviderPath is the workaround)

@mklement0 I believe he's just answering your question of:

What file-system location should sf:/ - the root of all special folders - represent? There is no natural candidate, yet we don't want to disallow Set-Location sf:/ altogether, given that it works with other providers (e.g., Set-Location alias:/ works just fine); if location sf:/ doesn't represent an actual file-system item - just as alias:/ doesn't -  the problem doesn't arise.

with "it doesn't, it's like alias:/".

Also I agree with you that making the content of the leaf be the path is the only way to implement it as a provider.  It is gonna be weird though that Get-ChildItem sf:Desktop won't work like folks expect.  I know it can't do that with how providers work currently, but still maybe too confusing.

Thanks, @SeeminglyScience, but I was trying to point out that only if you conceive of the provider underlying the sf drive as a file-system provider do you have to solve the problem of what file-system location sf:/ maps to. So, if we want Get-ChildItem sf:Desktop to work - to avoid confusion - we indeed need to implement the provider as a file-system provider - and then we need to solve that problem.

I really don't think you can in a way that doesn't cause more confusion.  Unless you just special case all path resolution starting in sf in the FileSystemProvider itself.
The biggest obstacle in any provider implementation that is "sorta like X provider but with this one difference" is that you can't do cross provider operations.  So Copy-Item sf:\Desktop C:\temp is hardwired to throw.  Also how does path resolution transition between providers like gi sf:\Desktop\Chrome.lnk.  The provider API just isn't built to handle any of that.
Sorry if that's all already been mentioned ITT.

Sorry if that's all already been mentioned ITT.

I don't think it has, @SeeminglyScience, so thanks for clarifying.
So it sounds like the conclusion is:

A provider underlying the proposed sf drive currently cannot be a special-cased  file-system provider, so we currently cannot support calls such as Set-Location sf:Desktop or Get-Item sf:Desktop, even though users may expect it.

As a provider whose items simply represent path strings, namespace variable notation (e.g, $sf:Desktop) works as intended - which is what matters - and it still supports discovery via Get-ChildItem / Get-Item; Set-Location sf:/ - in the absence of needing to map to a file-system location - then presents no conceptual problem.

A provider underlying the proposed sf drive currently cannot be a special-cased  file-system provider, so we currently cannot support calls such as Set-Location sf:Desktop or Get-Item sf:Desktop, even though users may expect it.

Maybe clarify that Get-Item will work, just not return a DirectoryInfo object.

Interesting, we expect  that sf:\Desktop returns a value but alias:% does not return ForEach-Object. It looks like a fundamental problem.

@iSazonov ${alias:%} does return ForEach-Object

But we want Set-Location $sf:Desktop, not Set-Location ${sf:Desktop}

$sf:Desktop will work just fine, the brackets are because % isn't allowed in variable names.

>alias:gcm
alias:gcm: The term 'alias:gcm' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

It is not expanded to Get-Command.

alias:gcm is a bareword, there is nothing to expand here.

@iSazonov, that is expected, because alias:gcm isn't a file-system path that allows direct execution. Only the alias provider understands this path, so you'll have to use Get-Item alias:gcm (or Get-Content alias:gcm to just get the definition of the alias, which is the string `'Get-Command').

If we allowed direct execution of variables, we would not need temporary files.

that is expected, because alias:gcm isn't a file-system path

What do we want - sf:Desktop or $sf:Desktop in Set-Location?

What do we want - sf:Desktop or $sf:Desktop in Set-Location?

The only way that can work with how providers currently work is $sf:Desktop.
Though I want to state again that I think this design is too confusing for folks who don't know why it needs to be like that.  Personally I think this should wait until cross provider path resolution/copy operations work.

@SeeminglyScience
I get the potential for confusion, but there's no telling if and when cross provider path resolution/copy operation will ever be implemented (or are there specific plans?), so I don't think we should wait for that.
I see the primary utility of the proposed feature in composing path strings via string interpolation / concatenation, where $sf:Desktop is the necessary form (e.g., "$sf:Desktop/subdir" (however, with Join-Path the confusion could again arise).
If we implement a provider now and make its items containers of type [System.IO.DirectoryInfo] (and the item content their .FullName property), then we could conceivably later transition to a fully integrated specialized file-system provider - or am I missing something?
Come to think of it: Would that alone enable Set-Location sf:Desktop, given that there's no cross-provider operation happening? However, you then wouldn't actually change to a location on drive sf:, instead; you'd change directly to the native file-system path underlying the item - but that is arguably preferable.
@yecril71pl

If we allowed direct execution of variables

There is no variable here (whose value you can invoke with &), only a literal path referring to an item exposed by the Alias provider (via its one and only alias: drive).
@iSazonov
PowerShell conceptually could - but currently doesn't - accept path alias:gcm as a command to execute, even though the System.Management.Automation.AliasInfo instance the path refers to is by definition a command (derives from System.Management.Automation.CommandInfo). Given that just gcm is sufficient for invocation, however, I don't think that's a shortcoming in practice.
Out of curiosity, @SeeminglyScience: is this problem solvable with how providers currently work?
By contrast, for paths such as sf:Desktop to become first-class PS file-system citizens, alongside custom PS filesystem drives, we'd need a specialized file-system provider, which
according to @SeeminglyScience's analysis a problem that cannot be solved with how providers currently work.

but there's no telling if and when cross provider path resolution/copy operation will ever be implemented

Yeah I know, still.  A different route should be pursued imo.

If we implement a provider now and make its items containers of type [System.IO.DirectoryInfo] (and the item content their .FullName property), then we could conceivably later transition to a fully integrated specialized file-system provider - or am I missing something?

I think is a bigger understandability challenge.  The Get-Item object is a DirectoryInfo, but it's a leaf, and the content is the path.  Then later we're going to make them no longer a leaf and throw on Get-Content?  Even if that was intuitive, that makes it even harder for a user to determine why gci sf:/Desktop or gi sf:/Desktop/pwsh.lnk don't work.

Come to think of it: Would that alone enable Set-Location sf:Desktop, given that there's no cross-provider operation happening? However, you then wouldn't actually change to a location on drive sf:; instead, you'd change directly to the native file-system path underlying the item - but that is arguably preferable.

Nah, you can't set your location to a leaf.

PowerShell conceptually could - but currently doesn't - accept path alias:gcm as a command to execute, even though the System.Management.Automation.AliasInfo instance the path refers to is by definition a command (derives from System.Management.Automation.CommandInfo). Given that just gcm is sufficient for invocation, however, I don't think that's a shortcoming in practice.
Out of curiosity, @SeeminglyScience: is this problem solvable with how providers currently work?

Well & (gi alias:gcm) works.  I imagine a really basic version could maybe be hooked up via ItemCmdletProvider.InvokeDefaultAction if the breaking change was accepted.  But execution in the same way it works for the filesystem provider could be a big ol' can of worms.

Thanks, @SeeminglyScience.

The Get-Item object is a DirectoryInfo, but it's a leaf

The proposal was to make it a container, but, yes, allowing Get-Content to report the container's path would be an anomaly (something like Get-Content $HOME currently fails, as does ${C:\Windows}, with Unable to get content because it is a directory:)
However, conversely that means that if we wait until we can make the sf: drive's provider a specialized, full-fledged file-system provider, it is $sf:Desktop that won't work - which takes away what I perceive to be the primary use case: I want to be able to use $sf:Desktop/file.txt, and not be forced to use "$(Get-Item sf:Desktop)/file.txt" or (Get-Item sf:Desktop/file.txt).FullName - which is both cumbersome and inefficient.
So, to me the pragmatic solution is: implement a provider whose items are leaf items that represent path strings - and make it clear in the documentation that sf:-based paths cannot serve directly as file-system items.

Well & (gi alias:gcm) works

Sure, and so does & $alias:gcm (though a string is returned in that case), but the question was whether the detour via Get-Item / namespace variable notation can be avoided in this case.
The question was more academic, though: given the negligible benefit from enabling this and the potential for pitfalls, I agree that it's not worth tackling.

The proposal was to make it a container, but, yes, allowing Get-Content to report the container's path would be an anomaly (something like Get-Content $HOME currently fails, as does ${C:\Windows}, with Unable to get content because it is a directory:)

That is again pretty confusing imo.  As an aside I don't think it's a good idea to allow a container to work with Get-Content just for this workaround.

However, conversely that means that if we wait until we can make the sf: drive's provider a specialized, full-fledged file-system provider, it is $sf:Desktop that won't work - which takes away what I perceive to be the primary use case: I want to be able to use $sf:Desktop/file.txt

Yeah I totally get the use case.

Same way you resolve file system paths though.  Also Resolve-Path.

So, to me the pragmatic solution is: implement a provider whose items are leaf items that represent path strings - and make it clear in the documentation that sf:-based paths cannot serve directly as file-system items.

If it had to be added as it's own provider, that'd be the only way that it could be implemented currently.  I don't think it should be though, it'd be way too difficult to understand.
Honestly I'd rather see it as special casing the FileSystemProvider's path resolution.  I'm not really sure if it's worth the extra complication, but that would at least be very easy to understand.

Sure, and so does & $alias:gcm (though a string is returned in that case), but the question was whether the detour via Get-Item / namespace variable notation can be avoided in this case.

Yeah I gotcha, the rest of the sentence was the direct answer.

I don't think it's a good idea to allow a container to work with Get-Content just for this workaround.

Agreed.

Same way you resolve file system paths though. Also Resolve-Path

Yes, but that is cumbersome for this use case.

If it had to be added as its own provider, that'd be the only way that it could be implemented currently. I don't think it should be though, it'd be way too difficult to understand.

If the primary usage is $sf:Desktop in path strings, I don't think people would think twice about it, just like they don't think about $env:HOME being underpinned by a provider operation that is the equivalent of Get-Content Env:HOME.
With proper tab-completion, you may never need to touch the provider cmdlets, and if you think of $sf:Desktop as just a special variable (value), Set-Content $sf:Desktop isn't a stretch either.

Yes, but that is cumbersome for this use case.

Could you elaborate? You'd only need to do this if you were passing the path to something that didn't understand PSPath's.  Otherwise it'd work similar to a PSDrive.

If the primary usage is $sf:Desktop in path strings, I don't think people would think twice about it, just like they don't think about $env:HOME being underpinned by a provider operation that is the equivalent of Get-Content Env:HOME.

Environment variables aren't just paths though, users already think of them like variables.

Could you elaborate?

I want to be able to use $sf:Desktop/file.txt, which I can't if sf:Desktop is a container (directory) item.

Environment variables aren't just paths though, users already think of them like variables.

That's my point: users can and should think of $sf:Desktop as (special) variables that contain path strings.
Underpinning this with a provider is simply a technical requirement to enable this syntax.

I want to be able to use $sf:Desktop/file.txt, which I can't if sf:Desktop is a container (directory) item.

Right I got that, but why do you want that instead of working it into actual path resolution.
Why do you need to do:
Copy-Item $sf:Desktop/pwsh.lnk ./pwsh.lnk

Instead of
Copy-Item sf:/Desktop/pwsh.lnk ./pwsh.lnk

That's my point: users can and should think of $sf:Desktop as (special) variables that contain path strings.
Underpinning this with a provider is simply a technical requirement to enable this syntax.

I understand how you want it to be viewed, but I think that's challenging.  Introducing a provider whose content is a file system path as a string that you then pass to a different provider to be resolved to an item is inherently difficult to understand.

I understand how you want it to be viewed

It's more than that: I'm proposing that it be actively framed this way: to de-emphasize the provider aspect as an implementation detail, which avoids the conceptual problems. Instead, we should frame $sf:* as special variables that return path strings.
In that vein:
Copy-Item sf:/Desktop/pwsh.lnk ./pwsh.lnk

I have no idea what sf:/Desktop is (I'm playing ignorant to make a point) - all I know is that $sf:Desktop returns the platform-appropriate Desktop path string that I can use as part of larger path strings - just like I would use $env: variable notation; e.g.:
Copy-Item $env:ProgramFiles/foo/bar.exe ./bar.exe

If sf: is a file drive why should it work another than Temp: drive?

Because that would require sf: to be a drive in the file system.

If we allowed direct execution of variables

There is no variable here (whose value you can invoke with &), only a literal path referring to an item exposed by the Alias provider (via its one and only alias: drive).

A variable named SCRIPT.PS1 has a literal path of VARIABLE:SCRIPT.PS1.  So, when I pass VARIABLE:/SCRIPT.PS1 as a command, I expect the script in the variable to be executed.  But that is not allowed and I have to put the script onto the file system in order to be able to execute it.

@iSazonov
sf: would be a PowerShell drive, but not a PowerShell file-system drive - it currently cannot be the latter, for the technical reasons explained by @SeeminglyScience, but even if it could (it's unclear if and when), it would introduce more problems than it solves.
(I've come full circle on this: the original proposal was to not conceive of it as a file-system drive, then we discussed what it would take to do so, now I'm back to the original proposal).
Just like alias: or env: aren't file-system drives, sf: wouldn't be either: it would be a drive that exposes items representing strings that happen to be file-system path strings (just like many environment variables on Windows contain file-system paths, such as $env:ProgramFiles).
The primary purpose of the sf: drive would be to enable namespace variable notation, so that something like $sf:Desktop expands to the path string that is the platform-appropriate native file-system Desktop path, and can be used as-is in building longer paths ($sf:Desktop/file.txt) and calls that expect native file-system paths.
Just like most users rarely, if ever, interact with the Env: drive via provider cmdlets - they instead rely on namespace variable notation such as $env:ProgramFiles - they would just use $sf:Desktop, or tab-completion for discovery. (Of course, they can use Get-ChildItem sf: for more convenient and sophisticated discovery, if they choose to.)

The only technical reason I can think of is that SF:/, unlike TEMP:/, would not correspond to any actual location, so it would be a virtual drive with effective links inside, a bit like \\.\, which is an interesting idea better left to be implemented by the underlying OS than by ourselves.

@mklement0

[...] (note: Desktop and DesktopDir, though technically distinct, seem to refer to the same location in practice; the former is distinguished from the latter as being the "logical Desktop rather than the physical file system location" - not sure what that means).

Desktop
DesktopDirectory

Note to the uninitiated: Just to be confusing, "the shell" refers to an entirely different component of Windows than PowerShell or cmd.exe. You probably know it as explorer.exe, though naturally most of it is actually implemented in DLLs ...
I think this distinction is/was only relevant with SHGetSpecialFolderLocation and SHGetFolderLocation, which build paths in the shell's namespace (ITEMIDLIST structures, also called PIDLs for some reason). CSIDL_DESKTOP would give you the thing that's actually represented on your desktop; CSIDL_DESKTOPDIRECTORY would give you the place you get to when you type e.g. %USERPROFILE%\Desktop into Explorer's address bar.
[The documentation seems to imply that both values do the same thing since Vista, but I'm not going to assume that's actually true.]
In particular, CSIDL_DESKTOP would have whatever extra items [Computer, Recycling Bin, etc.] the user has configured to appear on the desktop, as well as items contributed from CSIDL_COMMON_DESKTOPDIRECTORY (i.e. the All Users desktop shortcuts).
Naturally, none of this is in any way relevant to the return value of System.Environment.GetFolderPath.

is there any reason no one raised a Get-SpecialFolder cmdlet?

I just got pointed to this issue. The whole subject certainly deserves careful consideration and design, but this may perhaps help someone now:
Several years ago I had created a PS module for inspecting and manipulating known folders using the COM API (which provides much more functionality than the legacy API used internally by the .NET Environment class). I wanted to ease my pain of mass redirecting the folders (including the Public ones) out of the system drive when setting up multiple computers for several members of my family - by default possible only by clicking in the GUI (and requiring temporarily disabling UAC to move the Public folders). The goal was to be able to write
# as any user
Get-KnownFolder | Move-KnownFolder -Destination F:\Profiles\$Env:UserName
# single folder, with rename
Move-KnownFolder -SingleFolder (Get-KnownFolder -Name Personal) -NewPath D:\Data\$Env:UserName\Docs
# as admin
Get-KnownFolder -Public | Move-KnownFolder -Destination F:\Profiles\Public

The module is fully functional (I tend to use it any time I set up a new computer); I just ran out of free time and motivation to make the finishing touches - writing some docs/examples and publishing to PSGallery. I could probably make that effort if there is interest.
For inspecting the paths we would use:
PS C:\> (Get-KnownFolder -Name Personal).Path
F:\Profiles\jberezanski\Documents

My implementation is obviously Windows-only; I don't know how many of the Windows Shell concepts are applicable to other platforms. When I thought about exposing more of those concepts in PS, I tended to think in terms of a provider + drive - Shell:\, with the root representing the Shell namespace root (the "logical" Desktop). However, I did not come upon actual use cases for navigating that namespace and all my practical needs were satisfied by the two cmdlets mentioned above.

(Personally, I'd love to see a cross platform way for referencing the AppData/Local AppData known folders, so that applications could stop polluting the root of the user profile directory with their config/data files and folders, but that is a different rant altogether.)

Thanks, @jberezanski.

I don't know how many of the Windows Shell concepts are applicable to other platforms

I've summarized which known folders apply to which platforms above.
While I think that Get-KnownFolder would make a nice addition (I've created a function of the same name for myself a while back), I think that something like $sf:Desktop is also called for:
Specifically, it would lessen the temptation to write code such as 'hi' > $HOME/Desktop/foo.txt, given that the only fully robust formulation would be the more verbose 'hi' > "$(Get-KnownFolder Desktop)/foo.txt" (note the required double quotes; a Join-Path command would be even more verbose).
Being able to use 'hi' > $sf:Desktop/foo.txt is the best of both worlds: robust and convenient.

Being able to use 'hi' > $sf:Desktop/foo.txt is the best of both worlds: robust and convenient.

Fully agreed.
I also don't see the syntax as confusing; many commonly used environment variables contain paths and we do things like mkdir $Env:TEMP\xyz all the time. I think it's not that difficult to learn that another prefix gives access to an additional set of paths - that a new provider is in the works there is an implementation detail, not important in the typical use case of just wanting to know the path.

And, possibly, writing to $sf:Something could perform the equivalent of my Move-KnownFolder...
...or maybe not, because then it would be too easy to do it by accident and the operation may be dangerous to user data.

Yes, I think that would be too dangerous, so a Move-KnownFolder cmdlet is preferable, although - unlike Get-KnownFolder - it would be Windows-specific.

By the way, the Environment+SpecialFolder enum, being based on the legacy pre-Vista SHGetFolderPath function, is missing a lot of Known Folders added in Vista and later (some of them rather useful), like Downloads, CommonDownloads, SavedPictures, Camera Roll, UserProgramFiles, OneDrive and many more.
In fact, the Known Folders API allows applications to register new folders with the system, so the list is not fixed.
I ran this on my system to see which Known Folders with non-empty paths were covered by the SpecialFolder enum/GetFolderPath method and out of 95 such Known Folders 46 are not exposed by GetFolderPath:
$specialFolderPaths = [enum]::GetValues([Environment+SpecialFolder]) | % { $p = [Environment]::GetFolderPath($_); [pscustomobject]@{SFName=$_; Path=$p}}
$allKnownFolders = Get-KnownFolder -All
$knownFoldersWithNonEmptyPath = $allKnownFolders | ? Path -ne $null | select Category,Name,CanRedirect,Path
$knownFoldersJoinedWithSpecialFolderPaths = $knownFoldersWithNonEmptyPath | % { $kf = $_; $sfp = $specialFolderPaths | ? Path -eq $kf.Path; $kf | select *,@{Name='SFP';Expression={$sfp}}}
$allKnownFolders | measure | select -expand Count
139
$knownFoldersJoinedWithSpecialFolderPaths | measure | select -expand Count
95
$knownFoldersJoinedWithSpecialFolderPaths | ? SFP -eq $null | measure | select -expand Count
46

On Windows, I'd like to be able to access all Known Folders present on the system (the implementation could enumerate them during initialization). On other platforms a certain basic set should probably be defined, as described earlier in this thread (but not necessarily limited to [Environment+SpecialFolder] values).
One thing to note - some Known Folder names contain spaces ("Camera Roll"); this should not be a problem with the proposed syntax, because we already need to deal with problematic characters in environment variable names (${Env:ProgramFiles(x86)}).


[material-ui][Select] No visible preselection when focus is on another Element

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Link to live example:
https://react-tgv59j-vsvdvu.stackblitz.io

Steps:

Open link
Click on dropdown
Preselection for "Twenty" is visible
If i hit "T" on the keyboard, the selection goes to the next option
Now eiher click the button below, or click the button, hold the left mouse cursor, drag it somewhere else on the whitespace, and release it
If you click the dropdown again, nothing is preselected, at least visibly
If you hit "T",  the second element is instantly selected

ALSO:
If you hit "Enter" in Step 6 without selecting any other element, "Twenty" will be selected. So i assume it is preselected, but not visibly.
Current behavior 😯
After clicking the button, the preselection is not visible anymore.
Expected behavior 🤔
I would either expect "Twenty" already being visibly preselected in Step 6, or the Keyboard Action of  Step 7 selecting the first Element.
Context 🔦
I currently have an issuew with keyboard controlls sometimes not working for some dropdowns in my application. When the keyboard controlls do not work, there is also nothing preselected.
I assume this is part of the issue.
Your environment 🌎
See stackblitz live example environment.
Browser was Chrome.

Hey @supidupicoder2, thanks for the report!
This seems like a bug. I can repro on the docs:

Click another element so it gains focus
Open Select
No visible highlight, but the highlight is "working" as keyboard navigation works: after pressing the ArrowDown key, the highlight kicks in again

https://github.com/mui/material-ui/assets/16889233/71f57bae-80f5-4fcd-8fff-acdd66d17c03

Hi @DiegoAndai, I noticed that when the user focuses on another element before opening the select dropdown menu, also has no preselection.
i.e.

Click on button first
Open drop down
It has no preselection

Given that there is no default value selected, it is expected for the basic dropdown menu to be preselected or not?

@JeevaRamanathan, for the Menu component, this is expected: there's no "default" highlight on the first element.
For the Select component, it's not expected: the first element should be highlighted if no value is selected. That is what this issue is pointing out.

@DiegoAndai Should I take this?

@DarhkVoyd please! go ahead 😊
Let me know if there's anything I can help with

Hi @DiegoAndai. Apologies for the delay, I'm quite occupied with my college project and might not be able to work on this issue promptly. If it's urgent, kindly reassign it to someone else. Thanks for your understanding.

@DiegoAndai Hey, I'm back on this, will provide an update to you soon.

This will be fixed when we refactor the Select component to use Base UI's hooks: https://github.com/mui/material-ui/pull/40210


Add new extensions

deprecate duplicated methods in SwifterSwift.swift
new Date extensions
new URLRequest extensions
new UIWebView extensions
new UserDefaults extensions
updated CHANGELOG

Dang, I was hoping there was the date extensions I needed. I need to figure out if a date is in this week or in this year 😃 I'll add them after I complete it