Scribbles for my bad memory

Sometimes we need to run shopt -s dotglob nullglob before moving files including dotfiles. So there's another question, do we need to set it back afterward? The most correct answer is

It's usually not clear if either dotglob or nullglob were already set before running shopt -s to set them. Thus, blindly un-setting them may not be the proper reset to do. Setting them in a subshell would leave the current shell's settings unchanged:

( shopt -s dotglob nullglob; mv /public/* /public_html/ )

Reference: Jeff Schaller's answer under this question

It's a rather interesting feature. I first use it the same way as the python tuple type. I immediately found I was wrong. It doesn't support using an index to visit certain element

Stupid enough. I think. Soon I found the correct way, you know, the Item1, Item2 way.

It's so Stupid! Then I found the best way: the named element way.

Task<(List<string> orderIdList, List<string> orderNoList)> GetExpiringOrderIdListAndOrderNoList(DateTime checkTime);

Ok. It's not very stupid.

1. Create a middleware to do that task

    public static void SetCurrentCulture(this IApplicationBuilder app)
    {
        app.Use(async (context, next) =>
        {
            var cultureQuery = context.Request.Headers["lang"] == "en" ? "en-US" : "zh-CN";
            if (!string.IsNullOrWhiteSpace(cultureQuery))
            {
                var culture = new CultureInfo(cultureQuery);
                CultureInfo.CurrentCulture = culture;
                CultureInfo.CurrentUICulture = culture;
            }
            await next();
        });
    }
   

2. Use the middleware in Startup.cs

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env, ILog logger,
        IExceptionEntityService exceptionEntityService)
    {
        ...
        app.SetCurrentCulture();
        ...
    }
   

I had written the following code in a project

   ...
   return s && s.value || null

It works well for some days until a colleague did some code refactoring. In the beginning, s.value is a string value, and an empty string is not a valid value, so the code works well. After the refactoring, s.value became an integer, and this time 0 is a valid value. So you can imagine when s.value === 0 the code above will return null instead of 0. It leads to a bug!

Therefore please use the"A || B" expression with caution!