Re: pagefile.sys is reported as being a directory

[Thomas Wolff via Cygwin]

Am 03.05.2024 um 01:40 schrieb Bruno Haible via Cygwin:

Hi,

Ken Brown noticed this: pagefile.sys and swapfile.sys are being
reported by Cygwin 3.5.3 as being directories.

Cygwin 3.5.3 on Windows 10:

$ ls -ld /proc/cygdrive/c/pagefile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/pagefile.sys
$ ls -ld /proc/cygdrive/c/swapfile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/swapfile.sys

In Cygwin 2.9.0 and 3.4.6 (also on Windows 10) it was reported as a regular 
file:

Also still worked in 3.5.1.


$ ls -ld /proc/cygdrive/c/pagefile.*
-rw-r- 1 Unknown+User Unknown+Group 671088640 May  3 01:25 
/proc/cygdrive/c/pagefile.sys
$ ls -ld /proc/cygdrive/c/swapfile.*
-rw-r- 1 Unknown+User Unknown+Group 268435456 May  3 01:25 
/proc/cygdrive/c/swapfile.sys

Gnulib is interested in the modification time of this file.

Do you agree that it's a bug?

Do you have a workaround? In Gnulib we wish to have a way to access this file,
that works on all versions of Cygwin.

Bruno







--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Change for the initial installation of Cygwin to set the default terminal terminal 256 color

[Thomas Wolff via Cygwin]

Am 12.04.2024 um 11:18 schrieb Lee via Cygwin:

On Fri, Apr 12, 2024 at 4:05 AM J M  wrote:

Some examples that I view that can do Cygwin better by default:

tput colors
8

echo $TERM
xterm

I made my mintty changes by point & click experimentation - if you
want to make system-wide changes the place to do that is in
/etc/minttyrc
   https://github.com/mintty/mintty/wiki/Tips
   Configuring mintty
   For its configuration, it reads configuration files in this order:
   /etc/minttyrc
   ... etc.

$ grep -i term .minttyrc
Term=xterm-256color

$ tput colors
256

$ echo $TERM
xterm-256color

Note that mintty always supports all modes, including 256 colours and
true-color (TERM=xterm-direct), regardless of the TERM setting or the
$TERM environment value. That value is only used by some applications
(like tput and apparently vim) as an indication which features to use.
Thomas




And if use vim, comparing with one Ubuntu terminal:

I need to set "set mouse-=a" because the copy paste is difficult.
The colors are very bright.
The cursor does not look good when doing a search and moves over the yellow
background text.

What settings would I need to make it look like Ubuntu's vim?

I'd suggest doing a 'man vim' to find out where all the possible
configuration files are & then copy them to your cygwin machine.

Regards,
Lee


El jue., 11 abr. 2024 14:36, J M  escribió:


Hi,

You can change in the initial install setup of Cygwin to set the default
terminal to 256 color as Ubuntu does?



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: ls/stat on OneDrive causes download of files

[Thomas Wolff via Cygwin]

Am 08.03.2024 um 11:37 schrieb Corinna Vinschen via Cygwin:

Hi Jeffrey,

On Mar  6 13:55, Jeffrey Altman via Cygwin wrote:

On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote:

We can add an explicit call to

RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS);
[...]

Files and directories that are placeholders should have either the
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS or FILE_ATTRIBUTE_RECALL_ON_OPEN file
attributes set. When these attributes are set, applications and mini filters
are advised not to "read" or "open" the files or directories unless they
absolutely need to because doing so will cause the placeholder to be
replaced by an object containing the actual data which might take a long
time to fetch,

Yesterday I stumbled over a certain NtCreateFile flag:

   FILE_OPEN_NO_RECALL (0x0040)

 Instructs any filters that perform offline storage or virtualization
 to not recall the contents of the file as a result of this open.

MS-CIFS described it like this:

   FILE_OPEN_NO_RECALL
   0x0040

 In a hierarchical storage management environment, this option
 requests that the file SHOULD NOT be recalled from tertiary storage
 such as tape. A file recall can take up to several minutes in a
 hierarchical storage management environment. The clients can specify
 this option to avoid such delays.

This sounds like we could simply add this flag to all NtOpenFile
used for path conversion or stat-like calls, without having to care
for any file attributes specificially.

Does that make sense?

Sounds good, without even studying the other details...
I speculate some more handling would still be needed to avoid executable
detection via magic tags.

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Desktop partially inert with mintty running

[Thomas Wolff via Cygwin]

Am 15.02.2024 um 09:23 schrieb Bruce Jerrick via Cygwin:

Has anyone had this happen:

Sometimes when I have a mintty running, the upper-left quandrant of the
desktop
becomes inert to the mouse -- icons do not respond to hovers or clicks,
and the
desktop background does not respond to a right-click.
The remainder of the desktop behaves normally.

Everything becomes responsive again when the mintty is closed, but it takes
several seconds.

This happens under Windoze 10 and 11, and it has happened with cygwin 3.4.9,
3.5.0, and various 3.6.0 (test).  It also happened with previous versions of
mintty (and current version 3.7.0-1).

This is *very* intermittent; I can't reproduce it at will.


There is this report: https://github.com/mintty/mintty/issues/1243
but I wasn't able to reproduce it.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: mintty ^H weirdness with ssh to one specific Debian 11 system

[Thomas Wolff via Cygwin]

Am 18.01.2024 um 14:08 schrieb Andrey Repin via Cygwin:

Greetings, Jim Garrison via Cygwin!


Details
I have mintty set to term type "mintty"

Don't do that.
$TERM is not a random made-up string. It should be supported by appropriate
terminfo(5) entry on the system. If an entry is not found, it will fall back
to some other entry, which could be 'vt100' or even 'dumb', which is not what
you want, certainly.
Yes, I forgot to mention that. One way to check whether a terminal 
description addressed by your $TERM value is actually installed on the 
system, is to run the tool `infocmp`.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: mintty ^H weirdness with ssh to one specific Debian 11 system

[Thomas Wolff via Cygwin]

Am 16.01.2024 um 22:38 schrieb Jim Garrison via Cygwin:

TL;DR

New laptop, setting up mintty configuration identical to working 
desktop system.  When connected to one specific Debian 11 (Bullseye) 
system (to which I connect often from the desktop with no issues), 
backspace appears to send ^H, and Debian interprets ^H correctly, but 
the terminal display echoes a space character instead of backing up 
one space.


Details

I have mintty set to term type "mintty" and "Keys/Backarrow sends ^H".

A little experimentation shows that the Debian system is correctly 
interpreting the backspace, only the mintty display is incorrect. I 
guess there are two possibilities:


* Debian is echoing a blank when receiving ^H
* mintty is not correctly displaying the ^H echoed by Debian

Note, a local mintty session is NOT affected, backspace works fine there.

Also note when I ssh to a Debian 12 system and an old CentOS 7 system 
I don't see this issue, and when connecting from my desktop all three 
systems work.  I am stumped for how to troubleshoot this further.


I diffed the output of "stty -a" between the non-working system and 
one that works. The only differences are:


Working system: eol = ; eol2 = ;

Non-working system: eol = M-^?; eol2 = M-^?;

cygcheck.out attached


On the Debian 11 (non-working) system:

jhg@smtp ~
$ echo $TERM
mintty

jhg@smtp ~
$ stty -a
speed 38400 baud; rows 37; columns 128; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = M-^?; 
eol2 = M-^?; swtch = ; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; 
time = 0;

-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl 
ixon -ixoff -iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 
bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop 
-echoprt echoctl echoke -flusho -extproc


You've verified the stty setting 'erase' above, please also verify the 
mintty behaviour, e.g. with ^V Backarrow in a command line (to echo the 
character as ^H, hopefully) to check that the two settings match 
consistently.
I've noticed myself on an older Debian system that behaviour of the 
'erase' character may be weird; it initially worked as expected with ^H, 
then I switched to stty erase ^?, then back to ^H, and behaviour was 
different: ^H did not erase a character anymore but echoed "^H". Anyway, 
this is handling of the shell (or realine library) and not under control 
of mintty.

Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Automatic announcement generation by calm

[Thomas Wolff via Cygwin-apps]

Am 08/01/2024 um 13:35 schrieb Corinna Vinschen via Cygwin-apps:

On Jan  7 16:12, Jon Turney via Cygwin-apps wrote:

This is an experimental facility, currently only available for packages
deployed from the build service [1] (that is, not for self-built packages
uploaded with 'cygport up' via sftp)

When the token "announce" is present for a build job (in addition to
"deploy"), after a successful deploy, calm will automatically generate and
send an announce email.

The mail follows a similar format to that generated by "cygport announce",
containing a list of packages and the description, with the following
addition:

* If the cygport defines the variable "ANNOUNCE", it's evaluated contents
will be appended to the generated mail.

* Otherwise, if the source package contains an ANNOUNCE file [2], it's
contents will be appended.

* Otherwise, if the source package contains a README or ${PN}.README file,
lines that look like part of a changelog, between one starting with '
${PVR}' and the next starting '', will be extracted and appended

(None of these seem like a particularly great way of doing things, but they
match some historical patterns.  As always, suggestions about improvements
are welcome.)


In accordance with our long-standing policy of treating maintainer email
addresses as private information, the mail is sent from cygwin-no-reply and
bcc'ed to the uploader.


For testing purposes, if the token "mock" (yes, I am running out of synonyms
for "test"...) is also present, the mail will be only sent to the uploader,
not the announce list.


[1] https://cygwin.com/packaging/build.html
[2] Note that this isn't currently part of the default value of CYGWIN_FILES
[3], so needs to be explicitly listed there to be included in the source
package
[3] https://cygwin.github.io/cygport/src_prep_cygpart.html#CYGWIN_FILES

:+1:

Unfortunately I started the OpenSSH 9.6 build before reading this here,
but that's some great addition.

Corinna
I'd also appreciate to prefix the mail with an "[ANNOUNCEMENT] " tag as 
for the mails forwarded from cygwin-announcement to cygwin before that 
was stopped, to enhance the overview in users' mailboxes.

Thomas

Re: Automatic Cygwin installation for CI ?

[Thomas Wolff via Cygwin]

Am 15.12.2023 um 18:07 schrieb Mainz, Roland via Cygwin:

Hi!



Is there any documentation how Cygwin 3.5.0 can be automatically (without GUI 
and user intervention, e.g. via *.bat script) be installed as part of a CI 
(Continuous integration) build environment ?



Bye,
Roland
Appveyor CI provides a cygwin environment. You could try to find how 
they do it.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin api to punch a hole into a file?

[Thomas Wolff via Cygwin]

Am 05/12/2023 um 15:40 schrieb Thomas Wolff via Cygwin:

Am 05/12/2023 um 14:53 schrieb Corinna Vinschen via Cygwin:

On Dec  5 07:36, Thomas Wolff via Cygwin wrote:


Am 01.12.2023 um 12:02 schrieb Corinna Vinschen via Cygwin:

On Dec  1 11:22, Cedric Blancher via Cygwin wrote:

Not all filesystems have a 128k block/stripe size, and certainly most
filesystems have smaller minimum hole sizes than 128k (e.g. 512bytes
is common, ref pathconf _PC_MIN_HOLE_SIZE).

There's no _PC_MIN_HOLE_SIZE in Linux or POSIX.  In Windows, a sparse
file uses chunks of 64K.  You can see this even with a file of just
a single block.  Try this:

    $ touch x
    $ chattr +S x

    $ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x

    $ ls -ls x
    1 -rw-r--r-- 1 corinna vinschen 80 Dec  1 11:56 x

    [repeat echo and ls -ls until...]

    $ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x

    $ ls -ls x
    1 -rw-r--r-- 1 corinna vinschen 720 Dec  1 11:56 x
    $ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x

    $ ls -ls x
    64 -rw-r--r-- 1 corinna vinschen 800 Dec  1 11:56 x2
    ^^
    This

For me, it goes up from 1 to 4, then in steps of 4KB.

Is that a local NTFS, did you actually call

   chattr +S x

after touching the file, and did you check with

   lsattr x

that x is actually sparse?
Ups, sorry, I was just throwing my 2p into something. Yes, on a local 
NTFS; setting chattr +s does not change it but lsattr says:

---a .ls-s

So why does chattr not seem to work?
Sorry again, I failed to test properly (I had copied your `chattr +S x` 
which is not the filename I tested... blush).

With chattr +S, I reproduce your observation.


Thomas


Corinna







--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin api to punch a hole into a file?

[Thomas Wolff via Cygwin]

Am 05/12/2023 um 14:53 schrieb Corinna Vinschen via Cygwin:

On Dec  5 07:36, Thomas Wolff via Cygwin wrote:


Am 01.12.2023 um 12:02 schrieb Corinna Vinschen via Cygwin:

On Dec  1 11:22, Cedric Blancher via Cygwin wrote:

Not all filesystems have a 128k block/stripe size, and certainly most
filesystems have smaller minimum hole sizes than 128k (e.g. 512bytes
is common, ref pathconf _PC_MIN_HOLE_SIZE).

There's no _PC_MIN_HOLE_SIZE in Linux or POSIX.  In Windows, a sparse
file uses chunks of 64K.  You can see this even with a file of just
a single block.  Try this:

$ touch x
$ chattr +S x

$ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x
$ ls -ls x
1 -rw-r--r-- 1 corinna vinschen 80 Dec  1 11:56 x

[repeat echo and ls -ls until...]

$ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x
$ ls -ls x
1 -rw-r--r-- 1 corinna vinschen 720 Dec  1 11:56 x
$ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x
$ ls -ls x
64 -rw-r--r-- 1 corinna vinschen 800 Dec  1 11:56 x2
^^
This

For me, it goes up from 1 to 4, then in steps of 4KB.

Is that a local NTFS, did you actually call

   chattr +S x

after touching the file, and did you check with

   lsattr x

that x is actually sparse?
Ups, sorry, I was just throwing my 2p into something. Yes, on a local 
NTFS; setting chattr +s does not change it but lsattr says:

---a .ls-s

So why does chattr not seem to work?
Thomas


Corinna




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin api to punch a hole into a file?

[Thomas Wolff via Cygwin]

Am 01.12.2023 um 12:02 schrieb Corinna Vinschen via Cygwin:

On Dec  1 11:22, Cedric Blancher via Cygwin wrote:

Not all filesystems have a 128k block/stripe size, and certainly most
filesystems have smaller minimum hole sizes than 128k (e.g. 512bytes
is common, ref pathconf _PC_MIN_HOLE_SIZE).

There's no _PC_MIN_HOLE_SIZE in Linux or POSIX.  In Windows, a sparse
file uses chunks of 64K.  You can see this even with a file of just
a single block.  Try this:

   $ touch x
   $ chattr +S x

   $ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x
   $ ls -ls x
   1 -rw-r--r-- 1 corinna vinschen 80 Dec  1 11:56 x

   [repeat echo and ls -ls until...]

   $ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x
   $ ls -ls x
   1 -rw-r--r-- 1 corinna vinschen 720 Dec  1 11:56 x
   $ echo 
1234567890123456789012345678901234567890123456789012345678901234567890123456789 
>> x
   $ ls -ls x
   64 -rw-r--r-- 1 corinna vinschen 800 Dec  1 11:56 x2
   ^^
   This

For me, it goes up from 1 to 4, then in steps of 4KB.


I don't know how Windows stores short files, maybe they are part of the
metadata up to a point or some such.  However, as soon as you raise the
size over a given point, the *allocation size* will be rounded up to 64K
and from that point on, it will be in 64K chunks.  Also sparsifying and
desparsifying of blocks only works in 64K chunks.


Corinna



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin tool to differ junctions from soft links?

[Thomas Wolff via Cygwin]

Am 16.11.2023 um 21:30 schrieb Brian Inglis via Cygwin:

On 2023-11-16 11:55, matthew patton via Cygwin wrote:

On Thursday, November 16, 2023 at 03:50:24 AM EST, Andrey Repin wrote:
Does Cygwin have a command line tool (Scriptable!) which can be 
used to

differ between soft links and Windows junctions?


Distinguishing between types of Windows reparse points is not a POSIX 
or emulation function, so not of interest to Cygwin developers.


I thought about it when support was added, but then realized there was 
no nice place to add it within the platform, without going the 
non-portable Windows specific utility route, as in lsattr.


You could in a function or script by running lsattr -d which seems to 
fail on reparse points, then ls -dl which shows a Symbolic Link with a 
relative path, and a Junction with an absolute path, although it could 
just be a Symbolic Link with an absolute path.

lsattr has an explicit flag:
 'r', 'Reparse':   file or directory that has a reparse 
point
I don't know whether it's the same as a junction, otherwise a 'j' flag 
could be added.




Perhaps something like the following would be useful to Windows users 
who want to know this stuff:


https://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html


It would be easier to help you, if you specify the purpose of your
request. I.e. what you want to achieve with such tool.
AFAIK no. what I do is re-implement 'ln' with a wrapper because the 
Cygwin

behavior (Junctions) was driving me up the wall.
https://github.com/tb3088/shell-environment/blob/ccf7aa161899c2c4ebe2d9e980e674bc726a3ef3/.functions_os.CYGWIN_NT#L9 



Cygwin never creates Windows Directory or Filesystem Junction reparse 
points, and by default it uses its own version of Unix path symlink 
files, preceded by a flag ("magic cookie") value, and with system 
attribute, to allow compatibility with FAT file system limitations, or 
else NFS symlinks on NFS filesystems.


CYGWIN env var settings allow creation of Windows shortcuts and 
symbolic link reparse points instead of its default (equivalent to 
winsymlinks:sys), when supported by the file system and Windows release:


https://cygwin.com/cygwin-ug-net/using-cygwinenv.html

https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: sqlite3 outdate

[Thomas Wolff via Cygwin]

Am 13.10.2023 um 02:41 schrieb xvac--- via Cygwin:

zig lang
nim lang
rust lang

also should add to cygwin official repo.
The Rust project does not support build on cygwin (see 
https://github.com/rust-lang/rust/issues/79854).

Never heard of zig or nim.



Oct 13, 2023, 08:39 by x...@tuta.io:


Hi cygwin member,

I find sqlite3 and postgresql packages in cygwin is outdate, anyone can up it 
to latest?

also, many new CLI tools should add to cygwin official repo.
eg, `bun` :
https://github.com/oven-sh/bun








--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: half- and full-width CJK characters

[Thomas Wolff via Cygwin]

Am 08/10/2023 um 14:55 schrieb Dr Bean via Cygwin:

On Sat, 07 Oct 2023, Thomas Wolff via Cygwin wrote:



Am 07/10/2023 um 14:47 schrieb Dr Bean via Cygwin:

On Sat, 07 Oct 2023, Thomas Wolff via Cygwin wrote:


Am 07/10/2023 um 10:23 schrieb Dr Bean via Cygwin:

I am memorializing this for my own benefit here.

Benefitting fromhttps://eng-blog.iij.ad.jp/archives/12576
I see that I don't need to change any envars, but only fonts.

The default Lucida Console font renders CJK as half-width chars, on
this PC with 3 Windows language packs.

With MS ゴシック, Japanese かな and 漢字 look good.
Traditional Chinese ㄅㄛˋㄆㄛˋㄇㄛˋand 漢字 look good.
Korean 한글 doesn't look good. It looks like they're
half-width characters drawn with the space for one full-width
character.

I wonder if this is a problem with the Korean language pack.


Please describe the context of your observations (preferably a test case);
do you have an issue inside the Cygwin Terminal?
Thomas

All mintty contexts. Viewing this email in an SSH session in screen
to a remote tmux session on freeshell.org, writing this reply in vim,
and changing the mintty font option from ,

Font=Lucida Console
to
Font=ＭＳ ゴシック

the above CJK characters change appearance from half-width to full-width,
except for the Korean 한글, which doesn't change appearance.

Attaching to the tmux session on freeshell, sshing in from my
phone with Termius, the characters don't change, of course.

I'm not suggesting there's anything wrong with the default mintty font
option of Lucida Console. It looks good.

I am on the lookout for a good font for viewing korean 한글, so I
don't have to magnify the screen to read it.

By the way, thanks for mintty. It is a joy to use.


Judging by the name (which has Katakana characters), ＭＳ ゴシック is a
Japanese font, so maybe it simply does not have any special Korean
ideographs and the Windows font fallback mechanism substitutes some
unsuitable font.
You should try to find a specific Korean font, I doubt ＭＳ ゴシック was
provided by the Korean language pack. I could try to reproduce the issue if
you tell me which font it is. As far as I know, the CJK names are only used
with respective language packs installed, otherwise the same font can be
addresses by an alternative name. You could also look up the font filename
(in the Windows Fonts folder) to identify it. Thomas

In the mintty font option dropdown there are at least 2 (4?) fonts giving
full-width Korean 한글 here. I have the Windows Korean language pack
installed.

They are with filenames in /cygdrive/c/windows/Fonts:

BatangChe   batang.ttc
DotumChegulim.ttc
GulimChegulim.ttc
GungsuhChe  batang.ttc

And

ＭＳ ゴシック msgothic.ttc (the ＭＳ chars are full-width)
doesn't result in full-width hangul.

So, I've found a suitable font for Korean 한글.

Thanks for confirming. By the way, as CJK fonts are usually not very 
suitable for Latin text (mostly not being monowidth in the first place),
there is a useful mechanism in mintty that allows you to use your 
favourite CJK and non-CJK fonts together.

It's the FontChoice setting for secondary fonts:

|Font=Lucida Console ||Font2=|ＭＳ ゴシック
|FontChoice=CJK:2 |

Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: half- and full-width CJK characters

[Thomas Wolff via Cygwin]

Am 07/10/2023 um 14:47 schrieb Dr Bean via Cygwin:

On Sat, 07 Oct 2023, Thomas Wolff via Cygwin wrote:


Am 07/10/2023 um 10:23 schrieb Dr Bean via Cygwin:

I am memorializing this for my own benefit here.

Benefitting fromhttps://eng-blog.iij.ad.jp/archives/12576
I see that I don't need to change any envars, but only fonts.

The default Lucida Console font renders CJK as half-width chars, on
this PC with 3 Windows language packs.

With MS ゴシック, Japanese かな and 漢字 look good.
Traditional Chinese ㄅㄛˋㄆㄛˋㄇㄛˋand 漢字 look good.
Korean 한글 doesn't look good. It looks like they're
half-width characters drawn with the space for one full-width
character.

I wonder if this is a problem with the Korean language pack.


Please describe the context of your observations (preferably a test case);
do you have an issue inside the Cygwin Terminal?
Thomas

All mintty contexts. Viewing this email in an SSH session in screen
to a remote tmux session on freeshell.org, writing this reply in vim,
and changing the mintty font option from ,

Font=Lucida Console
to
Font=ＭＳ ゴシック

the above CJK characters change appearance from half-width to full-width,
except for the Korean 한글, which doesn't change appearance.

Attaching to the tmux session on freeshell, sshing in from my
phone with Termius, the characters don't change, of course.

I'm not suggesting there's anything wrong with the default mintty font
option of Lucida Console. It looks good.

I am on the lookout for a good font for viewing korean 한글, so I
don't have to magnify the screen to read it.

By the way, thanks for mintty. It is a joy to use.

Judging by the name (which has Katakana characters), ＭＳ ゴシック is a 
Japanese font, so maybe it simply does not have any special Korean 
ideographs and the Windows font fallback mechanism substitutes some 
unsuitable font.
You should try to find a specific Korean font, I doubt ＭＳ ゴシック was 
provided by the Korean language pack. I could try to reproduce the issue 
if you tell me which font it is. As far as I know, the CJK names are 
only used with respective language packs installed, otherwise the same 
font can be addresses by an alternative name. You could also look up the 
font filename (in the Windows Fonts folder) to identify it. Thomas


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: half- and full-width CJK characters

[Thomas Wolff via Cygwin]

Am 07/10/2023 um 10:23 schrieb Dr Bean via Cygwin:

I am memorializing this for my own benefit here.

Benefitting from https://eng-blog.iij.ad.jp/archives/12576
I see that I don't need to change any envars, but only fonts.

The default Lucida Console font renders CJK as half-width chars, on
this PC with 3 Windows language packs.

With MS ゴシック, Japanese かな and 漢字 look good.
Traditional Chinese ㄅㄛˋㄆㄛˋㄇㄛˋand 漢字 look good.
Korean 한글 doesn't look good. It looks like they're
half-width characters drawn with the space for one full-width
character.

I wonder if this is a problem with the Korean language pack.

Please describe the context of your observations (preferably a test 
case); do you have an issue inside the Cygwin Terminal?

Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Bonfire of the Packages

[Thomas Wolff via Cygwin-apps]

Am 24.09.2023 um 20:20 schrieb gstrauss via Cygwin-apps:

On Sun, Sep 24, 2023 at 01:32:59PM +0100, Jon Turney via Cygwin-apps wrote:

Generally, we have a large number of old, unmaintained packages.

The policy [1] has always been "Packages without an active maintainer may be
pulled from the distribution.", but not actively enforced (in fact prior to
2022, this used to say "are pulled", but I moderated the statement, just to
reflect reality).

I guess what's needed is an automated process which removes unmaintained
packages, after some period of time in that state.

I'm somewhat ambivalent about doing that, as they are probably of some use,
but on the hand I don't think our users are best served providing very old
packages with unknown numbers of bugs, security problems, etc., or which are
unsupported upstream.

Were the first steps to be performed by an automated process, I would
propose that the automated process mark and move packages
'pending delete' to a new category "abandoned", which is not installed
by default, but selectable in the cygwin setup.exe.  Alternatively,
'promote' the abandoned packages to "testing".  After a period of time
in "abandoned" or "testing", the packages could be removed to a holding
area, but not yet deleted, since this is the time that some people might
start to notice.  It would be nice to be able to restore packages
relatively quickly during this period.  Finally, after another period of
time passes, delete the package.

Cheers, Glenn
I have two packages that were not updated for 7 years for a while, for 
different reasons, but are still maintained.
What criteria would you have in mind? I don't think this is a reasonable 
approach.

Thomas

Re: Drop djgpp-{binutils,gcc-*,runtime} 32-bit packages

[Thomas Wolff via Cygwin-apps]

Am 24.09.2023 um 14:32 schrieb Jon Turney via Cygwin-apps:

On 08/09/2023 18:29, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Thinking we could drop the ancient (8 years) orphaned DJGPP 32-bit 
(by definition) packages; they are older than djgpp current, never 
mind beta on gcc 13; from DJ's latest Monthly Mini-FAQ summary:


 djdev-2.05 binutils-2.32 ... gcc-10.2.0 ...


Yeah, this seems like the right thing to do.
Unlike old Windows versions, MSDOS / DosBOX is still an environment 
appreciated by enthusiasts to run old games,
and having a cross-compiler for it is a nice thing. I wouldn't think 
it's harmful to keep them around.

Thomas

[ANNOUNCEMENT] Updated: mintty 3.6.5

[Thomas Wolff via Cygwin]

I have uploaded mintty 3.6.5 with the following changes:

Pathname handling
  * Fix file link detection (#1208), tweak URL detection (#1209).
  * Restore opening of Windows path names (#1219; broken since 2.8.1).

Terminal features
  * Fix setup of initial status line if monitor DPI is 96.
  * ESC/Enter restore alphanumeric keyboard input mode while IME is 
active (#1223).

  * OSC 50 query response is "?" after font setting failed.
  * Fix DECRQCRA Rectangular Checksum attribute handling.
  * Added DECSACE to DECRQSS (xterm 383).
  * Indicate keyboard layout code in status line.
  * Fix image display (iTerm2 protocol) in "Sixel display mode".
  * New DECSET 7780 "Image display mode" to keep cursor position on 
image output (#1228).

  * New parameter doNotMoveCursor for iTerm2-style image output (#1228).

Window handling
  * Revamp window operations, esp max/fullscreen, to not raise to 
foreground.

  * Group taskbar icons by setting -o Class (#1207).
  * Handling transparency in tab sets (#1152, #1069, ~#1128).
  * Workaround against dropping fullscreen on DPI change (#1226).
  * Preserve "normal position" (unzoomed) during screen changes (~#1226).

Configuration
  * New user-definable function compose (#1211).
  * New option setting ComposeKey=capslock (#1211).
  * New option ConfirmReset to guard confirm dialog on interactive 
reset (#1173).

  * Support changed Drag-and-drop format for some theme file downloads.
  * New option KeyAlphaMode (#1223).
  * New option -Rw to report the Windows window id.
  * New option StatusDebug to include debug information in the status line.

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: mintty window border?

[Thomas Wolff via Cygwin]

Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin:

On 2023-08-24, Backwoods BC via Cygwin wrote:

On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin
 wrote:

This is an update to a question I had a couple of years ago
https://cygwin.com/pipermail/cygwin/2021-April/248367.html

Windows 11 now has an "accent color" option under
Settings/Personalization/Colors that adds a thin (1px?) border around
all windows, in a user-selectable color.  This definitively eliminates
the problem seen with overlapping mintty windows that have a dark grey
or black background (where the shadow isn't visible).

Just FYI

--
Jim Garrison
j...@acm.org

This is also true for Windows 10, although I may have had to
explicitly enable it (I don't remember).

It's in the same place on Windows 10.  I just enabled it.  Thank you both!

But it adds the thin border only to the foreground window...
Thomas


Regards,
Gary





--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] cygwin 3.4.8-1

[Thomas Wolff via Cygwin]

Am 17.08.2023 um 19:59 schrieb Corinna Vinschen via Cygwin-announce via 
Cygwin:

The following packages have been uploaded to the Cygwin distribution:

* cygwin-3.4.8-1
* cygwin-devel-3.4.8-1
* cygwin-doc-3.4.8-1

Bug Fixes
-

- Make  safe for c89 compilations.
   Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html

- Make gcc-specific code in  compiler-agnostic.
   Addresses: https://cygwin.com/pipermail/cygwin/2023-July/253927.html

- Fix AT_EMPTY_PATH handling in fchmodat and fstatat if dirfd referres to
   a file other than a directory
   Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q2/012306.html

- Rename internal macros _NL_CTYPE_OUTDIGITSx_MB/WC to GLibc compatible
   _NL_CTYPE_OUTDIGITx_MB/WC.
   Addresses: 
https://cygwin.com/pipermail/cygwin-developers/2023-July/012637.html

- Fix memory leak in printf() regarding gdtoa-based _ldtoa_r().
   Addresses: https://cygwin.com/pipermail/cygwin/2023-July/254054.html

- Fix a bug introduced in cygwin 3.4.5 that open_shared() does not set
   access permissions as requested by its argument.


Is the recent fix in pty code not included in 3.4.8?
(https://sourceware.org/pipermail/cygwin-developers/2023-August/012657.html)
Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin console: Different default background color when terminal runs as Admin?

[Thomas Wolff via Cygwin]

Am 18.08.2023 um 10:11 schrieb Christian Franke via Cygwin:

Jonathon Merz via Cygwin wrote:
On Thu, Aug 17, 2023 at 7:13 PM Martin Wege via Cygwin 


wrote:


Just an idea: Could the default background color of the Cygwin console
be changed from black to grey (or RED) if the terminal has been
started with Administrator rights?


Assuming that:
1. The Administrators group is called "Administrators"
2. There aren't any non-administrative groups with "Administrators" 
in the

name
3. You're using mintty for your terminal

You can run the following in bash or zsh with the desired RGB values:

if [[ `id -Gn` == *Administrators* ]]
then
 echo -ne "\e]11;#FFBBEE\a";
fi


A alternative that should work with any shell, does not rely on 
(unfortunately localized) group names and only assumes that the 
Administrators group S-1-5-32-544 isn't remapped by /etc/group:


case " $(/usr/bin/id -G) " in
  *\ 544\ *) printf '\e]11;#80\a' ;;
esac

or like this
case " `id -G` " in
*" 544 "*|*" 0 "*)    echo admin;;
esac
Note the embedding spaces in the case expression.
I'm adding the 0 for a profile portable with Linux.
You could also use
    if id -G | grep -qE '\<(544|0)\>'
at the cost of an additional process creation.
In earlier Windows versions, you could also check for group 547 which 
was some kind of half-admin user.


Thomas



Or use a check of actual access rights:

if [ -r /proc/registry/HKEY_LOCAL_MACHINE/SAM/SAM ]; then ...; fi


I use this in .bashrc to add "(root)" to the default mintty title and 
set '#' as root prompt:


case " $(/usr/bin/id -G) " in
  *\ 544\ *) PS1=${PS1/\\e]0;\\w/\\e]0;\\w (root)}; PS1=${PS1/\\\$ /\# 
} ;;

esac




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Persistent and same Cygwin session for Windows login and ssh login?

[Thomas Wolff via Cygwin]

Am 18.08.2023 um 10:47 schrieb Corinna Vinschen via Cygwin:

On Aug 17 19:30, Cedric Blancher via Cygwin wrote:

Good evening!

How can I get a Cygwin session for one Windows login, and get the same
Cygwin session when I log into the same Windows machine via ssh?

You can't.  Windows isolates sessions from each other.
Not quite sure what you mean by session. Maybe you want to multiplex a 
session among terminals (and thus initial logins) with 'tmux' or 'screen'.


Thomas


Also, where does Cygwin store session information?

Nowhere, really.  Sessions are a Windows thing.  We only keep a bit of
transient stuff in various shared memory regions.


Corinna




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Entering Cygwin command line (bash login) from Windows cmd.exe ?

[Thomas Wolff via Cygwin]

Am 07.08.2023 um 06:02 schrieb Roland Mainz via Cygwin:

On Sat, Jul 29, 2023 at 6:18 AM Roland Mainz  wrote:

Is there an official way to enter the Cygwin command line (e.g. bash
login) from Windows cmd.exe, e.g. if someone ssh's into a Windows
machine he/she ends/up in a cmd.exe and not bash...
On the other hand, you could also stop the Windows ssh server, start the 
cygwin ssh server, to arrive in a cygwin shell directly.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Rare character glitch in pty?

[Thomas Wolff via Cygwin]

There was a report that on switching terminal windows with the mouse,
focus event reports (as enabled with ESC[?1004h) would sometimes get 
mangled.
This is further described in issue reports to mintty/wsltty 
(https://github.com/mintty/wsltty/issues/335) and also to tmux 
(https://github.com/tmux/tmux/issues/3601).


I could reproduce the issue without either of tmux or WSL. However, it 
happens only once in a few hundred instances:
The escape sequence is changed so that the initial ESC is replaced by 
one of the two subsequent characters, so instead of ESC[O, either of [[O 
or sometimes O[O would be sent to the foreground application.


I traced the issue down to the pty that connects mintty and its client 
application, verified that the correct sequence is passed into write() 
at the pty and the mangled sequence appears at read() in the client 
process. In addition to a minimised test program that behaves like `cat 
-v`, I also also put the test output directly into the client process 
within the mintty code.
This leaves the only conclusion that the issue must be happening somehow 
within pty handling, maybe in the context of some timing condition or 
Windows messages being passed to mintty.
Anyhow, I was about to prepare testing with older mintty versions, in 
case I overlooked something, when the OP reported that the issue does 
not happen with cygwin 3.2.0.

Is there any recent change that could possibly cause such weird behaviour?
Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] italic-man

[Thomas Wolff via Cygwin-apps]

Am 25.06.2023 um 15:36 schrieb Jon Turney:

On 21/06/2023 22:45, Thomas Wolff via Cygwin-apps wrote:


Am 16.02.2023 um 20:17 schrieb Thomas Wolff via Cygwin-apps:


Am 16.02.2023 um 19:59 schrieb Jon Turney:

On 21/01/2023 17:04, Thomas Wolff via Cygwin-apps wrote:
italic-man installs two scripts and hooks them into the workflow 
of the 'man' command so that the italic attribute of manual pages 
is actually displayed as italics in terminals that support it.


cygport file attached


Thanks very much for having another go at this.

I'm still not overly keen on postinstall/preremove scripts which 
modify a configuration file belonging to another package, so I 
think I'm going to defer to Achim on approving this.


Taking a step back, may I ask a couple of questions?

- Can this be done as a patch to man-db and/or groff?

(perhaps with a separate man-italic package which just contains a 
marker file which enables the functionality?)


- (If different) how would this be done in an upstreamable way?

Thanks for taking a look.
I understand your hesitation but there are a number of zp_ 
postinstall scripts around that make updates to mandb, mime db, 
desktop, various caches, maybe crontab.


There's a difference between updating a cache or db of files which 
exist on the filesystem after the package update and modifying a file 
which might be overwritten by reinstalling or updating a different 
package.


Well, yes, there could be a zp_ script for man that makes this entry 
to /etc/man_db.conf itself in the presence of the italic-man 
package. If that's desired and someone else updates man, I will 
cooperate on this.
I think the installation of italic-man does this in an upstreamable 
way except for the postinstall mechanism of course which seems to be 
different (if existent at all) everywhere.

Thomas
I've added a zp_man-db-italic.dash postinstall script as a proposal 
for man-db to address your concerns, to be found in the repository 
github.com/mintty/italic-man. However, I find not documentation about 
these zp_ things, it seems they are just all called after each setup. So 


They are briefly covered in [1].  If that's missing some details, 
please let me know and I'll see what can be done to improve it.


[1] https://cygwin.com/packaging-package-files.html#postinstall

would it actually make a difference whether the zp_ is a script of 
italic-man or of man-db? I've also added a cygport file to the 
repository so you can try the update if you like.
Still interested in your opinion about this question. Also whether it's 
OK that package italic-man provided a zp script that modified 
/etc/man_db.conf.



About your first question

- Can this be done as a patch to man-db and/or groff?
Do you mean the whole thing should not be a separate package at all 
but completely patched into man-db?


Well, yes, that would avoid all the knots caused by post-install 
scripts with uncertain ordering I'm worrying about.
I think I have addressed those uncertainties and the problem with the 
man-db patch is that man-db package maintainers would need to take up 
the issue...




Can you explain, in general terms, why this isn't a feature of stock 
man-db already?
There is option grotty -i in stock man-db but grotty is a tool deeply 
embedded in the man toolchain and there is no user-friendly documented 
way to inject this option into the toolchain, other than replacing 
grotty with a wrapper script which is effectively all my package does.




Looking forward to your opinion and that of the man-db package 
maintainer.
And yes, the hook works on Linux too, so it could be provided somehow 
upstream.


Thanks continuing to grind away at this.

Re: [ITP] italic-man

[Thomas Wolff via Cygwin-apps]

Am 16.02.2023 um 20:17 schrieb Thomas Wolff via Cygwin-apps:


Am 16.02.2023 um 19:59 schrieb Jon Turney:

On 21/01/2023 17:04, Thomas Wolff via Cygwin-apps wrote:
italic-man installs two scripts and hooks them into the workflow of 
the 'man' command so that the italic attribute of manual pages is 
actually displayed as italics in terminals that support it.


cygport file attached


Thanks very much for having another go at this.

I'm still not overly keen on postinstall/preremove scripts which 
modify a configuration file belonging to another package, so I think 
I'm going to defer to Achim on approving this.


Taking a step back, may I ask a couple of questions?

- Can this be done as a patch to man-db and/or groff?

(perhaps with a separate man-italic package which just contains a 
marker file which enables the functionality?)


- (If different) how would this be done in an upstreamable way?

Thanks for taking a look.
I understand your hesitation but there are a number of zp_ postinstall 
scripts around that make updates to mandb, mime db, desktop, various 
caches, maybe crontab.
Well, yes, there could be a zp_ script for man that makes this entry 
to /etc/man_db.conf itself in the presence of the italic-man package. 
If that's desired and someone else updates man, I will cooperate on this.
I think the installation of italic-man does this in an upstreamable 
way except for the postinstall mechanism of course which seems to be 
different (if existent at all) everywhere.

Thomas
I've added a zp_man-db-italic.dash postinstall script as a proposal for 
man-db to address your concerns, to be found in the repository 
github.com/mintty/italic-man. However, I find not documentation about 
these zp_ things, it seems they are just all called after each setup. So 
would it actually make a difference whether the zp_ is a script of 
italic-man or of man-db? I've also added a cygport file to the 
repository so you can try the update if you like.

About your first question

- Can this be done as a patch to man-db and/or groff?
Do you mean the whole thing should not be a separate package at all but 
completely patched into man-db?

Looking forward to your opinion and that of the man-db package maintainer.
And yes, the hook works on Linux too, so it could be provided somehow 
upstream.

Thomas

Re: mintty 3.6.4 status line problem

[Thomas Wolff via Cygwin]

Am 18.06.2023 um 22:00 schrieb Ross Boulet via Cygwin:

I was looking at the settings for mintty and saw the new option (new as of 
3.6.4 from March) for a status line. I decided to try it out. Sure enough, a 
status line appeared at the bottom. All was well until I tried to open a new 
mintty window and nothing seemed to happen. After a little research, I saw a 
stackdump was being generated. I had to get to the .minttyrc file and remove 
the StatusLine=yes to get it to work again. I tried the same scenario on 
another Windows 10 machine as well as a Windows 11 machine with the same 
results.

To reproduce the problem, right click on the icon in the upper left corner of a 
mintty window and choose options. On the options dialog, choose terminal and 
check the option to turn on the status line. Then click save. The current 
window shows a status line but attempts to start a new window will fail and 
generate a stackdump.

This issue occurs if the monitor DPI is 96 (or 100% display scaling).
It was fixed in the repository already. Still working on some other 
issues before a release though.

Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] cygwin 3.4.7-1

[Thomas Wolff via Cygwin]

Am 16/06/2023 um 16:25 schrieb Corinna Vinschen via Cygwin-announce via 
Cygwin:

The following packages have been uploaded to the Cygwin distribution:

* cygwin-3.4.7-1
* cygwin-devel-3.4.7-1
* cygwin-doc-3.4.7-1

Bug Fixes
-

- Fix CPU_SET(3) macro type mismatch by making the macros type-safe.
   Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html

- kill(1): don't print spurious error message.
   Addresses: https://cygwin.com/pipermail/cygwin/2023-March/253291.html

- Align behaviour of dirname in terms of leading slashes to POSIX:
   https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html

- Fix reading CONIN$ in non cygwin apps when stdin is not a pty.
   Addresses https://cygwin.com/pipermail/cygwin/2023-April/253424.html

This does not fix the test case yes | more.com .



- Fix bug in cygheap allocation size computation after fork.  Addresses:
   https://cygwin.com/pipermail/cygwin-developers/2023-April/012620.html

- Fix return value of ilogbl(NaN).
   Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253511.html

- Fix error handling in readlinkat.
   Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253510.html

- Fix return code and errno set by renameat2, if oldfile and newfile
   refer to the same file, and the RENAME_NOREPLACE flag is set.
   Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253514.html





--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: mouse behavior with vim

[Thomas Wolff via Cygwin]

[just removing mintty from the mail topic as it's quite obviously not 
related to it]


Am 19.05.2023 um 00:11 schrieb Jose Isaias Cabrera via Cygwin:

On May 18, 2023 5:12 PM, Brian Inglis  expressed:

That will depend on the client installed on the remote host!
Get them to upgrade to gvim 9 as on Windows ;^>

I don't think that will do anything. :-)
This is the ubuntu version:
jic@web:~/w/default.website$ gvim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Apr 18 2023 11:40:57)
Included patches: 1-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919
Modified by team+...@tracker.debian.org
Compiled by team+...@tracker.debian.org
Huge version with GTK3 GUI.  Features included (+) or not (-):

This is the cygwin version:
$ gvim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24)
Included patches: 1-4372
Modified by 
Compiled by 
Huge version with GTK3 GUI.  Features included (+) or not (-):

I think it's a font issue. The ubunty server just has the bare minimun for X. 
It's probably just defaulting to the lowest fonts resolution available.

  

and the other that looks good is doing, ssh jic@web
password:
$ vim w/default.website/Musicos.html
This latter displays so much clearer and colorful, while the GVim
under X is ugly, dark and the font is not sharp. Any
thoughts/suggestions/help would is appreciated. Thanks.

That is just running on the default remote terminal ...xterm... something.
Check what your ssh is running under, then specify that in your remote command, 
before your vim command.

Hm... ok. Thanks.




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: xterm 380

[Thomas Wolff via Cygwin]

I have uploaded xterm 380.
Major changes:

 * DEC VT320 status line support
 * improved calculation of dim attribute colour


Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

cygport injects unexpected parameter

[Thomas Wolff via Cygwin-apps]

I'm trying to build xterm 380 and got two problems in the cygport 
compile step:


1.
*** ERROR: could not determine the autoconf version used to generate 
./configure; perhaps set AUTOCONF_VERSION?


I don't know why a tool wants to be told its own version (or what's 
going on) but the following line in xterm.cygport seems to help:

AUTOCONF_VERSION=$( autoconf --version | sed -e "s,.* ,," -e 1q )

2.
configure: error: unrecognized option: --docdir=/usr/share/doc/xterm

This seems to be injected by the cygconf function, and the package 
configure script does not know it.


Thomas

Re: Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11

[Thomas Wolff via Cygwin]

Am 04.04.2023 um 17:13 schrieb Yuta SUZUKI via Cygwin:

Hi,

I am recently setting up the computer room of my faculty
and then encountered the following issue:

Short description:
Change the default home directory via
/etc/nsswitch.conf
and make a new Windows user.
Login to the new user (and do not logout) and launch cygwin.
After opening another application's window, e.g. Explorer,
and try to switch the focus between the cygwin window and the other window.
After once or twice of switch, switching is not smooth
and both the cygwin and the other application seem freezing.
(Still we can launch powershell to restart the machine.)

Procedure to reproduce the issue:
1. Login as an administrator.
2. Install cygwin with the default configuration.
3. In C:\cygwin64\etc\nssswitch.conf, replace
# db_home:  /home/%U
to
db_home: /%H/cygwin
and save the file.
4. Create a new Windows user, say "test", without Microsoft account.
5. Logout from the administrator user used so far.
6. Login as the user "test". (Do not logout in the remaining steps.)
7. Launch cygwin from the desktop icon.
8. Run cygcheck -s -v -r > cygcheck_before_crash.out (to reproduce the
issue, this step is unnecessary.)
9. Open a window of the Explorer.
10. Click the cygwin window. This does not switch the focus to the focus...
11. Click the cygwin icon in the task bar. Probably it switches the window.
12. Run cygcheck -s -v -r > cygcheck_after_crash.out (to reproduce the
issue, this step is unnecessary.)
13. Click the Explorer window. This does not switch the focus to the focus...
14. Click the "x" mark on the top right of the cygwin window. This
does not close the window...
16. Close the cygwin from the task bar. Probably it closes the window.

For me, the behaviour in the step 11, 14, 15 are rather troublesome.
If the situation is worse, then I cannot even use the start menu to
turn off the machine.
In such a case, still I could launch PowerShell with keyboard and run
Restart-Computer -Force
to restart the machine.

Note that if you logout and re-login after the step 6
or if you are using Windows 10, then the issue is not reproduced.

Environment:
Edition Windows 11 Home
Version 22H2
Installed on ‎3/‎29/‎2023
OS build 22621.1413
Experience Windows Feature Experience Pack 1000.22639.1000.0

I attach the above two log files.
(Some Japanese is included, sorry: some translations are
"なし" = "not applicable"
and
"ローカル アカウント" = "local account")

I would appreciate it very much if someone would solve this issue.

Yours,
Yuta Suzuki
First, the symptoms you describe are not a "crash". Is the terminal 
actually still responsive (even if with delay)?

I cannot reproduce such an issue.
Please also cross-test with another terminal, e.g. rxvt, or xterm (after 
running an X server).

Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: mintty 3.6.4

[Thomas Wolff via Cygwin]

I have uploaded mintty 3.6.4 with the following changes:

Highlight
  * Dynamic support for flags emojis, deployment script.

Terminal features
  * Tweak response code to XTQALLOWED OSC 60 and XTQDISALLOWED OSC 61 
(xterm 378).

  * Readline mouse modes (DECSET 2001 / 2002 / 2003, xterm 379).
  * Hover and open URL: support parentheses (#1196).
  * Fix cursor artefacts in connection with ClicksPlaceCursor=yes.
  * Fix mouse-paste while still selecting.
  * Support multi-line progress detection.

Windows integration
  * Manage user-set HOME for calling Windows from WSL 
(mintty/wsltty#324, ~mintty/wsltty#76).

  * Support OSC 7 directory cloning if cloning WSL window while in rootfs.

Configuration
  * Status line is configurable in Options menu, switchable from 
context menu.

  * New user-definable function toggle-tabbar (#1201).
  * Setting ClicksPlaceCursor presets all readline mouse modes.
  * Dynamic support for flags emojis, deployment script 
(~mintty/wsltty#321).

  * `MINTTY_DEBUG=C mintty ...` will list loaded config files (#1181).
  * New option ProgressScan.

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: newlocale: Linux incompatibility

[Thomas Wolff via Cygwin]

Am 23.03.2023 um 20:48 schrieb Ken Brown via Cygwin:
I'm reporting this here rather than the newlib list because the 
behavior is compatible with Posix but not Linux, so I think it's a 
Cygwin issue.


Consider the following test case:

$ cat locale_test.c
#include 
#include 

int main ()
{
  const char *locale = "en_DE.UTF-8";
  locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
  if (!loc)
    perror ("newlocale");
  else
    printf ("newlocale succeeded on invalid locale %s\n", locale);
}

$ gcc -o locale_test locale_test.c

$ ./locale_test.exe
newlocale succeeded on invalid locale en_DE.UTF-8

On Linux, the newlocale call fails with ENOENT, as is documented on 
the man page.  Posix doesn't say what should happen on an invalid 
locale, so this is not, strictly speaking, a bug.
So the question is what is an invalid locale. In Linux, locales are only 
valid if explicitly listed somewhere.
This strict behaviour may be a problem. A much better approach is to 
allow any combination of known language_REGIOIN tags with encoding 
indications, to be much more flexible and dynamic.
So if such combinations are considered legal, as in cygwin, this is not 
a bug.




Ken

P.S. I noticed this because of a failing Emacs test.  No one else has 
reported this test failure, so it seems that newlocale fails on an 
invalid locale on all platforms supported by Emacs other than Cygwin.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: 'bat' for cygwin

[Thomas Wolff via Cygwin]

Am 10.03.2023 um 19:18 schrieb marco atzeri via Cygwin:

On Fri, Mar 10, 2023 at 6:58 PM Scott Smith via Cygwin wrote:

Has anyone compiled bat for cygwin64?

If not, could it be added for consideration to be added to the
repository, please?

Meanwhile, although I know 0% about Rust, if someone can tell me how to
install Rust, then I could take a shot at compiling it myself.

Thanks


Hi Scott,
sorry but , there is no rust compiler for Cygwin
Also Rust does not support a cygwin build: 
https://github.com/rust-lang/rust/issues/79854



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: ACL

[Thomas Wolff via Cygwin-apps]

Am 21.02.2023 um 14:10 schrieb Jonathan Chapman-Moore via Cygwin-apps:

Hi,


I was wondering when ACL was going to be added to Cygwin?

It's long been available, see /bin/[gs]etfacl

Re: [ITP] italic-man

[Thomas Wolff via Cygwin-apps]

Am 16.02.2023 um 19:59 schrieb Jon Turney:

On 21/01/2023 17:04, Thomas Wolff via Cygwin-apps wrote:
italic-man installs two scripts and hooks them into the workflow of 
the 'man' command so that the italic attribute of manual pages is 
actually displayed as italics in terminals that support it.


cygport file attached


Thanks very much for having another go at this.

I'm still not overly keen on postinstall/preremove scripts which 
modify a configuration file belonging to another package, so I think 
I'm going to defer to Achim on approving this.


Taking a step back, may I ask a couple of questions?

- Can this be done as a patch to man-db and/or groff?

(perhaps with a separate man-italic package which just contains a 
marker file which enables the functionality?)


- (If different) how would this be done in an upstreamable way?

Thanks for taking a look.
I understand your hesitation but there are a number of zp_ postinstall 
scripts around that make updates to mandb, mime db, desktop, various 
caches, maybe crontab.
Well, yes, there could be a zp_ script for man that makes this entry to 
/etc/man_db.conf itself in the presence of the italic-man package. If 
that's desired and someone else updates man, I will cooperate on this.
I think the installation of italic-man does this in an upstreamable way 
except for the postinstall mechanism of course which seems to be 
different (if existent at all) everywhere.

Thomas

Re: OpenSSH_9.2p1 sftp prompt now "s " instead of "sftp> "

[Thomas Wolff via Cygwin]

Am 08.02.2023 um 03:17 schrieb Brian Inglis via Cygwin:

On 2023-02-07 15:22, Voris, Ben via Cygwin wrote:

For example:
: sftp user@127.0.0.1
Connected to 127.0.0.1.
s bye
: type sftp
sftp is hashed (/usr/bin/sftp)
: ssh -V
OpenSSH_9.2p1, OpenSSL 1.1.1s  1 Nov 2022
On Linux with a much older ssh:
: ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020
: sftp user@127.0.0.1
Connected to 127.0.0.1.
sftp> bye
Windows 10 21H2. This occurs both using Mintty and Windows Terminal.
For what I do, the only issue is the prompt.


++


Yes, it sends s^[[7G^D, which is really weird.

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ITP] italic-man

[Thomas Wolff via Cygwin-apps]

italic-man installs two scripts and hooks them into the workflow of the 
'man' command so that the italic attribute of manual pages is actually 
displayed as italics in terminals that support it.


cygport file attachedNAME=italic-man
VERSION=1.0
RELEASE=1
ARCH=noarch

SUMMARY="Enabling italic display in manual pages"
CATEGORY="Utils Doc"
HOMEPAGE=https://github.com/mintty/italic-man
DESCRIPTION="italic-man installs two scripts and hooks them into the workflow 
of the 'man' command so that the italic attribute of manual pages is actually 
displayed as italics in terminals that support it."
LICENSE="GNU GPL V3"

SRC_URI=https://github.com/mintty/$NAME/archive/$VERSION/$NAME-$VERSION.tar.gz

SRC_DIR=.

src_compile() {
:
}

src_install() {
cd $S/$NAME-$VERSION
doman italic-man.7
insinto /usr/share/${NAME}
doins grotty iroff
insinto /etc/postinstall
newins postinstall ${NAME}.sh
newins postinstall zp_${NAME}.sh
insinto /etc/preremove
newins preremove ${NAME}.sh
}

Re: compiling issue

[Thomas Wolff via Cygwin]

Am 21.01.2023 um 06:19 schrieb Nathan via Cygwin:

The file here for a game I wanted to use is
http://www.ifarchive.org/if-archive/games/source/Adventure2.5.tar.gz and it
all compiled but one file getting the error is init.c  as follows:

Leaving out result types isn't legal C nowadays.
You could compile with
gcc -std=c90


gcc -O  -c init.c

init.c:167:1: warning: return type defaults to 'int' [-Wimplicit-int]

   167 | initialise() {

   | ^~

init.c: In function 'initialise':

init.c:169:13: warning: implicit declaration of function 'quick_init'
[-Wimplicit-function-declaration]

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   | ^~

init.c:169:27: warning: implicit declaration of function 'raw_init'
[-Wimplicit-function-declaration]

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   |   ^~~~

init.c:169:39: warning: implicit declaration of function 'report'
[-Wimplicit-function-declaration]

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   |   ^~

init.c:169:49: warning: implicit declaration of function 'quick_save'
[-Wimplicit-function-declaration]

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   | ^~

init.c:170:9: warning: implicit declaration of function 'finish_init'
[-Wimplicit-function-declaration]

   170 | finish_init();

   | ^~~

init.c: At top level:

init.c:173:8: warning: return type defaults to 'int' [-Wimplicit-int]

   173 | static raw_init() {

   |^~~~

init.c:173:8: error: static declaration of 'raw_init' follows non-static
declaration

init.c:169:27: note: previous implicit declaration of 'raw_init' with type
'int()'

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   |   ^~~~

init.c:369:8: warning: return type defaults to 'int' [-Wimplicit-int]

   369 | static finish_init() {

   |^~~

init.c:369:8: error: static declaration of 'finish_init' follows non-static
declaration

init.c:170:9: note: previous implicit declaration of 'finish_init' with type
'int()'

   170 | finish_init();

   | ^~~

init.c:593:8: warning: return type defaults to 'int' [-Wimplicit-int]

   593 | static report() {

   |^~

init.c:593:8: error: static declaration of 'report' follows non-static
declaration

init.c:169:39: note: previous implicit declaration of 'report' with type
'int()'

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   |   ^~

init.c:635:8: warning: return type defaults to 'int' [-Wimplicit-int]

   635 | static quick_init() {

   |^~

init.c:635:8: error: static declaration of 'quick_init' follows non-static
declaration

init.c:169:13: note: previous implicit declaration of 'quick_init' with type
'int()'

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   | ^~

init.c: In function 'quick_init':

init.c:648:9: warning: implicit declaration of function 'quick_io'; did you
mean 'quick_init'? [-Wimplicit-function-declaration]

   648 | quick_io();

   | ^~~~

   | quick_init

init.c: At top level:

init.c:655:8: warning: return type defaults to 'int' [-Wimplicit-int]

   655 | static quick_save() {

   |^~

init.c:655:8: error: static declaration of 'quick_save' follows non-static
declaration

init.c:169:49: note: previous implicit declaration of 'quick_save' with type
'int()'

   169 | if(!quick_init()){raw_init(); report(); quick_save();}

   | ^~

init.c:667:8: warning: return type defaults to 'int' [-Wimplicit-int]

   667 | static quick_io() {

   |^~~~

init.c:667:8: error: static declaration of 'quick_io' follows non-static
declaration

init.c:648:9: note: previous implicit declaration of 'quick_io' with type
'int()'

   648 | quick_io();

   | ^~~~

make: *** [Makefile:8: init.o] Error 1

  

  


so any tips or suggestions to fix this would be appreciated.

  


Thank you.

  

  

  

  

  






--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] ffmpeg (5.1.2)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 16:58 schrieb Takashi Yano via Cygwin-apps:

On Fri, 20 Jan 2023 16:47:01 +0100
Thomas Wolff wrote:

Am 20.01.2023 um 16:28 schrieb Takashi Yano via Cygwin-apps:

On Fri, 20 Jan 2023 16:04:46 +0100
Thomas Wolff wrote:

Am 20.01.2023 um 11:35 schrieb Takashi Yano via Cygwin-apps:

I would like to propose new package ffmpeg which is
well known audio/video tool. ffmpeg is ported to
many linux distributions and other unix like systems
as well as widows. Since there is windows build,
the demand of cygwin port might be relatively small,
however its libraries are usefull for other softwares.

I have posted another ITP for MOC (Music On Console)
which is a ncurses based music player, whose plugin
uses ffmpeg libraries.

I have already prepared the ffmpeg package as follows.

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/

To build ffmpeg, other new packages i.e., x264, x265 and
xvidcore are required, I have proposed ITP at the same
time.


It's also missing cygswscale-6.dll which I don't find anywhere.

It should be in:

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/libffmpeg/libffmpeg-5.1.2-1.tar.xz

which is reuqired by ffmpeg-5.1.2-1.tar.xz.

OK, I had overlooked that in the ffmpeg folder.
Now I get:

C:/cygwin64/bin/ffmpeg.exe: error while loading shared libraries: ?:
cannot open shared object file: No such file or directory

Thanks for testing.

You need libSDL2_2.0_0 package installed as described in
https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/ffmpeg-5.1.2-1.hint
A first test suggests that this build may be significantly (~70%) slower 
than the native Windows build of ffmpeg, unfortunately. Do you see a 
possible reason for that and a chance to compensate?

Re: [ITP] ffmpeg (5.1.2)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 16:28 schrieb Takashi Yano via Cygwin-apps:

On Fri, 20 Jan 2023 16:04:46 +0100
Thomas Wolff wrote:

Am 20.01.2023 um 11:35 schrieb Takashi Yano via Cygwin-apps:

I would like to propose new package ffmpeg which is
well known audio/video tool. ffmpeg is ported to
many linux distributions and other unix like systems
as well as widows. Since there is windows build,
the demand of cygwin port might be relatively small,
however its libraries are usefull for other softwares.

I have posted another ITP for MOC (Music On Console)
which is a ncurses based music player, whose plugin
uses ffmpeg libraries.

I have already prepared the ffmpeg package as follows.

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/

To build ffmpeg, other new packages i.e., x264, x265 and
xvidcore are required, I have proposed ITP at the same
time.


It's also missing cygswscale-6.dll which I don't find anywhere.

It should be in:

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/libffmpeg/libffmpeg-5.1.2-1.tar.xz

which is reuqired by ffmpeg-5.1.2-1.tar.xz.

OK, I had overlooked that in the ffmpeg folder.
Now I get:

C:/cygwin64/bin/ffmpeg.exe: error while loading shared libraries: ?: 
cannot open shared object file: No such file or directory

Re: [ITP] ffmpeg (5.1.2)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 11:35 schrieb Takashi Yano via Cygwin-apps:

I would like to propose new package ffmpeg which is
well known audio/video tool. ffmpeg is ported to
many linux distributions and other unix like systems
as well as widows. Since there is windows build,
the demand of cygwin port might be relatively small,
however its libraries are usefull for other softwares.

I have posted another ITP for MOC (Music On Console)
which is a ncurses based music player, whose plugin
uses ffmpeg libraries.

I have already prepared the ffmpeg package as follows.

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/

To build ffmpeg, other new packages i.e., x264, x265 and
xvidcore are required, I have proposed ITP at the same
time.


It's also missing cygswscale-6.dll which I don't find anywhere.

Re: [ITA] libsndfile (1.2.0)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 11:34 schrieb Takashi Yano via Cygwin-apps:

I would like to take over the maintenance of libsndfile
package which is currently orphanded. I have already
prepared the updated package at:

https://tyan0.yr32.net/cygwin/x86_64/release/libsndfile/


The archive appears to be empty.

Re: Feature request: sudo

[Thomas Wolff via Cygwin]

Am 19.01.2023 um 20:17 schrieb Jochen Wiedmann via Cygwin:

Hi,

as someone who is quite used to typing

   sudo do something

I would really like to do the same in my CygWin bash.In my opinion,
this could be implemented
relatively simply, and straightforward as follows:

   - Accept an array of strings with the command, that is being
executed with administrator
 privileges.
   - Use the standard Windows API to execute some functionality with
admin privileges.
 In the current case, that functionality would be a simple exec
with the above command line.

The result would be a sudo executable without some of the configurable
features of the
Linux/Unix sudo (like execution without password,  or execution of
special command lines
without root privileges), but just the same for all practical
purposes. I think, that a lot of users
would benefit.

Thanks,

Jochen

There used to be a su tool in cygwin.
See future of su 
 and 
"su" command removed / coreutils-8.23-2 
 for 
some discussion.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: GCC doesn't find relative includes when passed paths using backward-slashes

[Thomas Wolff via Cygwin]

Am 15.01.2023 um 14:51 schrieb Hans-Bernhard Bröker via Cygwin:

Am 15.01.2023 um 13:38 schrieb Alexander Grund via Cygwin:

The build system, finding it is running on Windows, will pass paths 
with backward slashes to the compiler. 


And that's wrong.  Cygwin is not, for practical intents and purposes, 
Windows.  It just runs on top of it.


Yes, backslashed path names do work in some cases on Cygwin (note that 
in the case at hand, you did have to "" around the name for that to 
work).  But at some point that idea has to be given up to achieve the 
primary goal of emulating a Unix-like environment.


The correct solution thus becomes "Don't do that, then."  Fix the 
build system detection to recognize Cygwin as a type of Unix, and 
things will almost certainly just work.



It also depends on how your application, in this case gcc or rather cpp, 
handles path names.
If it uses library functions dirname and basename, it should work as you 
expect, but maybe it looks for '/' itself, so you cannot expect all 
applications to be patched for cygwin/Windows pathname support.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

calm hint files

[Thomas Wolff via Cygwin-apps]

Upload seems to want two hint files, which even have to be different;
one needs a homepage entry, the other must not have one, or an error 
will be reported.

Can this please be smoothed out?
Thomas

[ANNOUNCEMENT] Updated: mintty 3.6.3

[Thomas Wolff via Cygwin]

I have uploaded mintty 3.6.3 with the following changes:

Terminal features
  * Fixed double-width characters not to wrap if auto-wrap disabled.
  * TAB may wrap to next line, or cause subsequent wrap, if enabled 
(#1182).

  * Fixed auto-wrap behaviour in double-width lines.
  * Overstriking character writing mode also switched with DECSET 20 
(VK100, #1184).

  * Fixed OSC 7 (set working directory) to handle ~ prefix.
  * Added XTQMODKEYS state query (xterm 373).
  * Withdrawn DEC private SGRs (/#1171, conflict with XTQMODKEYS).
  * Added XTQALLOWED OSC 60 and OSC 61 (xterm 373).

Unicode and Emoji data
  * Extend emoji information by considering Unicode file emoji-test.txt.

Configuration
  * Option WrapTab (#1182).
  * New user-definable function toggle-opaque (#1168), replaces 
transparency-opaque.


Other
  * Fixed crash in Options dialog when Printer Service is stopped (#1185).

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple