makedepend does not honor UNC path for -I and -Y

[Ronald Hoogenboom]

cygwin makedepend collapses the double-slash UNC path prefix to one single 
slash. It fails to find headers via such search paths.

Cygwin 3.2.0-1 on windows server 2012 R2
makedepend 1.0.6


-- 
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: Renaming (with 'mv') very large files is SLOW

[L A Walsh]

On 2022/01/31 13:36, Adam Dinwoodie wrote:



Could it be that the first 'mv' triggered an anti-virus read of the file since
perhaps it detects it as a new/changed file?

But if so, would 'mv' (under Task Manager) be showing the 100+ MB/s disk 
activity?



That definitely seems plausible; there's a reason a significant number
of the applications that are known to interfere with Cygwin operation
(see [0]) are antivirus applications.  But what would trigger your
antivirus to want to scan a file, and how much work is required to do
that, is something you'll need to take up with your antivirus vendor,
I'm afraid.
  


   Something that most people don't realize, is that windows always
puts a lock on a file when it is going to READ it.  It's an advisory lock,
and usually, on a local file access, it can be removed by the user who
started the read  and it's not noticed.
   But if cygwin is accessing the file through some virtual table, Windows
might think it is on a separate virtual device -- like an indexing 
scanner that

indexes content, or anti-vir.

This becomes real noticeable if it is a real remote file on a remote fs.

   In samba there's a setting to allow breaking advisory locks -- and 
if you
are the only person who can be accessing that file, its best to allow 
them to
be broken -- only real useful if you have multiple users (or programs) 
trying to
modify the same file at the same time.  If the oplocks are held by 
another process

windows may return a 'file busy' so cygwin uses a file-copy method to 'move'
the file.  I usually only run into this locally when the file is opened 
by a system
process when I try to modify it, like deleting a thumbs.db when explorer 
is updating

it.

The param in samba is "fake oplocks = yes", tells samba to fake oplocks 
and not
really enforce them.  It's a per-share parameter, so you need to set it 
on every

share.  But only on shares where you are the only 'modifier'.  For actual
shared-access w/other users -- only read-only access should be used.

   If you ever want to have local file caching of remote content work 
-- need to set

the oplocks to fake or have the files be read-only.




[0]: https://cygwin.com/faq/faq.html#faq.using.bloda

  


--
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

Removing ^X in paths

[Dennis Heimbigner]

It appears that windows now supports the UTF-8 codepage
and generally allows UTF-8 everywhere that ASCII was supported.
I light of this, it seems time to change cygwin so it no longer adds those
control-x (^X)  characters in e.g. path names.


--
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

Cntlm has crashed

[Tracen Subrayadoo via Cygwin]

Hi,

Cntlm has crashed with the below error:
1 [main] cntlm 20440 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. 
 Please report this problem to
the public mailing list cygwin@cygwin.com

Attached the dump.

Regards
Tracen

---
This email and any attachments may contain information that is confidential and 
subject to legal privilege. If you are not the intended recipient, any use, 
dissemination, distribution or duplication of this email and attachments is 
prohibited. If you have received this email in error please notify the author 
immediately and erase all copies of the email and attachments. The Ministry of 
Social Development accepts no responsibility for changes made to this message 
or attachments after transmission from the Ministry.

---


cntlm.exe.stackdump
Description: cntlm.exe.stackdump

-- 
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: Cntlm has crashed

[cygwinautoreply]

>--_004_481dbdafcf4f490cb61aa737e27f04fbsexch1301corpssigovtnz_
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable

>Hi,

>Cntlm has crashed with the below error:
>1 [main] cntlm 20440 find_fast_cwd: WARNING: Couldn't compute FAST_CWD point=
>er.  Please report this problem to
>the public mailing list cygwin@cygwin.com

>Attached the dump.

>Regards
>Tracen

>---
>This email and any attachments may contain information that is confidential=
> and subject to legal privilege. If you are not the intended recipient, any=
> use, dissemination, distribution or duplication of this email and attachmen=
>ts is prohibited. If you have received this email in error please notify the=
> author immediately and erase all copies of the email and attachments. The M=
>inistry of Social Development accepts no responsibility for changes made to=
> this message or attachments after transmission from the Ministry.

>---

>--_004_481dbdafcf4f490cb61aa737e27f04fbsexch1301corpssigovtnz_
>Content-Type: application/octet-stream; name="cntlm.exe.stackdump"
>Content-Description: cntlm.exe.stackdump
>Content-Disposition: attachment; filename="cntlm.exe.stackdump"; size=369;
>   creation-date="Thu, 03 Feb 2022 00:51:00 GMT";
>   modification-date="Thu, 03 Feb 2022 00:51:00 GMT"
>Content-Transfer-Encoding: base64

>U3RhY2sgdHJhY2U6DQpGcmFtZSAgICAgRnVuY3Rpb24gIEFyZ3MNCjAwNjFDN0M4ICA3NTY1N0U4
>OCAgKDAwMDAwMDAzLCAwMDYxQzgyMCwgMDAwMDAwMDAsIDAwMDAwM0U4KQ0KMDA2MUM5MzggIDYx
>MENFQTY0ICAoMDA2MUNBNTQsIDAwNjFDOUIwLCAwMDYxQzk5MCwgMDA2MUM5NzApDQowMDYxQ0FC
>OCAgNjEwQ0Y0N0IgICgwMDAwMDA0MCwgMDA2MUNCNjgsIDAwMDAwMDAwLCAwMDYxQzlEMCkNCjAw
>NjFDQzE4ICA2MTBEMzRBNSAgKDAwMDAwMDA0LCAwMDYxQ0M0MCwgMjAwMjgyODAsIDYxMTlEREI2
>KQ0KMDA2MUNEMDggIDYxMDA2RjU4ICAoMDAwMDAwMDAsIDAwNjFDRDU4LCA2MTAwNjU1MCwgMDAw
>MDAwMDApDQpFbmQgb2Ygc3RhY2sgdHJhY2UK

>--_004_481dbdafcf4f490cb61aa737e27f04fbsexch1301corpssigovtnz_
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline



>--_004_481dbdafcf4f490cb61aa737e27f04fbsexch1301corpssigovtnz_--

https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings

-- 
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: Removing ^X in paths

[L A Walsh]

On 2022/02/02 12:40, Dennis Heimbigner wrote:

It appears that windows now supports the UTF-8 codepage.
  

It has since early 2000's.

I light of this, it seems time to change cygwin so it no longer adds those
control-x (^X)  characters in e.g. path names.
  

^x is ASCII.  Cygwin doesn't insert ^X characters in paths.

Perhaps you are thinking of '\' which looks like ￥ (a capital 'Y' with 
2 horizontal lines, (Fullwidth Yen Sign  U+FFE5)...if that's the case, 
some 8-bit font

displayed that sign instead of a backslash in non-unicode locals.

Are you using a 32-bit or 64-bit version of Cygwin?  on what version of 
windows?


If you still use a 32-bit version, you might need to move to a 64-bit 
version.

I know the 32-bit version sometimes had the problem because it supported
fewer fonts and fewer characters at the same time.

You might check out your locale (if in english, try setting:
LC_CTYPE="en_US.UTF-8"
in your shell and also check that your used font has a backslash in the
0x7f position.

But in shell, ^x is usually a character to erase the whole line -- so it 
really

wouldn't do to have it in a PATH.

Hope this helps, and sorry if this is completely off base.

Linda



  



--
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 -C broken

[L A Walsh]

On 2022/01/28 07:46, Thomas Wolff wrote:
If I redirect output of `ls -C` (file / pipe), it used to produce 
well-formatted output in columns.
Suddenly it produces garbage formatting instead. As `ls` itself is not 
new, maybe it's some library that breaks behaviour?

Or even pty code?? Works on Cygwin 32-bit. Any idea?
Thomas
  

---
The authors of Gnu ls changed 'ls' defaults because "they can".

Old ls -C:
/bin/ls /proc
331  379  913   filesystems  mounts  registry32  swapsversion
332  500  cpuinfo   loadavg  net registry64  sys
335  731  cygdrive  meminfo  partitions  selfsysvipc
new ls -C:
/bin/ls /proc|cat
331
332
335
370
379
500
731
732
945
946
cpuinfo
cygdrive
devices
filesystems
loadavg
meminfo
misc
mounts
net
partitions
registry
registry32
registry64
self
stat
swaps
sys
sysvipc
uptime
version

---
with column:
law.Bliss> /bin/ls /proc|column (tabs mismatch)
331   731   devices   net   stat
332   732   filesystems partitions  swaps
335   952   loadavg   registry  sys
370   953   meminfo   registry32  sysvipc
379   cpuinfo   miscregistry64  uptime
500   cygdrive  mountsselfversion

with column+expand -8:
s> /bin/ls /proc|column|expand -8
1021379 devices net stat
1022500 filesystems partitions  swaps
331 731 loadavg registrysys
332 732 meminfo registry32  sysvipc
335 cpuinfo miscregistry64  uptime
370 cygdrivemounts  selfversion


---
several other tools no longer have settings to expand tabs to user-values
requiring the use of expand.

Formats of numeric output were also changed, requiring usage of 'numfmt'

This was all done to benefit script consistency at the expense of
users usability. It is expected that users can adapt to the computers.







by default, 'ls' will produce different output when it goes to the 
screen vs. when
it goes to a pipe.  When 'ls' goes to a pipe it is required to only use 
1 column.


To get the behavior you want, try piping through 'column' first (see 
'man (1) column).


They made many changes in core-utils to make automated shell scripts more
consistent at the expense of user-usability where they now suggest using
pipes into other utilities to get previous output

Try using ls|column.  Of course ls also used to expand tabs to every 8 
characters
and it no longer does that.  So you must use another util 'tabs' to set 
tabs to every

8th column (ls's standard tab setting)

--
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: Removing ^X in paths

[Dennis Heimbigner]

I am using 64bit.
And it has nothing to do misreading characters.

The ^X is described in this document: 
https://www.cygwin.com/cygwin-ug-net/using-specialnames.html,


There you will see this text:

"If you don't want or can't use UTF-8 as character set for
whatever reason, you will nevertheless be able to access the
file. How does that work? When Cygwin converts the filename from
UTF-16 to your character set, it recognizes characters which
can't be converted. If that occurs, Cygwin replaces the
non-convertible character with a special character sequence. The
sequence starts with an ASCII CAN character (hex code 0x18,
equivalent Control-X), followed by the UTF-8 representation of
the character. The result is a filename containing some ugly
looking characters. While it doesn't look nice, it is nice,
because Cygwin knows how to convert this filename back to
UTF-16. The filename will be converted using your usual
character set. However, when Cygwin recognizes an ASCII CAN
character, it skips over the ASCII CAN and handles the following
bytes as a UTF-8 character. Thus, the filename is symmetrically
converted back to UTF-16 and you can access the file."

There is no obvious good reason to continue this convention.


On 2/2/2022 7:23 PM, L A Walsh wrote:

On 2022/02/02 12:40, Dennis Heimbigner wrote:

It appears that windows now supports the UTF-8 codepage.

It has since early 2000's.
I light of this, it seems time to change cygwin so it no longer adds 
those

control-x (^X)  characters in e.g. path names.

^x is ASCII.  Cygwin doesn't insert ^X characters in paths.

Perhaps you are thinking of '\' which looks like ￥ (a capital 'Y' with 
2 horizontal lines, (Fullwidth Yen Sign  U+FFE5)...if that's the case, 
some 8-bit font

displayed that sign instead of a backslash in non-unicode locals.

Are you using a 32-bit or 64-bit version of Cygwin?  on what version 
of windows?


If you still use a 32-bit version, you might need to move to a 64-bit 
version.

I know the 32-bit version sometimes had the problem because it supported
fewer fonts and fewer characters at the same time.

You might check out your locale (if in english, try setting:
LC_CTYPE="en_US.UTF-8"
in your shell and also check that your used font has a backslash in the
0x7f position.

But in shell, ^x is usually a character to erase the whole line -- so 
it really

wouldn't do to have it in a PATH.

Hope this helps, and sorry if this is completely off base.

Linda








--
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

Log.text error

[Niclas Helbig]

Hello there,

The log Text told me to send you this.
I am no Code-wizzard, so I dont really know what this means.

I dont have Surface Wind Layer and WAFS Turbulence unfortunatly.
Would really like to fix that but dont know how.

Greetings,

Niclas
  0 [main] WIN32wgrib2 5128 find_fast_cwd: WARNING: Couldn't compute 
FAST_CWD pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
 328371 [main] WIN32wgrib2 5128 exception::handle: Exception: 
STATUS_STACK_OVERFLOW
 331088 [main] WIN32wgrib2 5128 open_stackdumpfile: Dumping stack trace to 
WIN32wgrib2.exe.stackdump
  0 [main] WIN32wgrib2 10104 find_fast_cwd: WARNING: Couldn't compute 
FAST_CWD pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
1:0:d=2022020218:PRMSL:mean sea level:9 hour fcst:
2:263017:d=2022020218:TMP:150 mb:9 hour fcst:
3:491150:d=2022020218:UGRD:150 mb:9 hour fcst:
4:669734:d=2022020218:VGRD:150 mb:9 hour fcst:
5:846211:d=2022020218:TMP:200 mb:9 hour fcst:
6:1076611:d=2022020218:UGRD:200 mb:9 hour fcst:
7:1259370:d=2022020218:VGRD:200 mb:9 hour fcst:
8:1441117:d=2022020218:TMP:300 mb:9 hour fcst:
9:1673187:d=2022020218:UGRD:300 mb:9 hour fcst:
10:1863564:d=2022020218:VGRD:300 mb:9 hour fcst:
11:2058164:d=2022020218:TMP:400 mb:9 hour fcst:
12:2282507:d=2022020218:UGRD:400 mb:9 hour fcst:
13:2466463:d=2022020218:VGRD:400 mb:9 hour fcst:
14:2655380:d=2022020218:TMP:500 mb:9 hour fcst:
15:2877717:d=2022020218:UGRD:500 mb:9 hour fcst:
16:3054789:d=2022020218:VGRD:500 mb:9 hour fcst:
17:3234940:d=2022020218:TMP:600 mb:9 hour fcst:
18:3460754:d=2022020218:UGRD:600 mb:9 hour fcst:
19:3633291:d=2022020218:VGRD:600 mb:9 hour fcst:
20:3807624:d=2022020218:TMP:700 mb:9 hour fcst:
21:4038732:d=2022020218:UGRD:700 mb:9 hour fcst:
22:4211679:d=2022020218:VGRD:700 mb:9 hour fcst:
23:4386381:d=2022020218:TMP:850 mb:9 hour fcst:
24:4638098:d=2022020218:UGRD:850 mb:9 hour fcst:
25:4815995:d=2022020218:VGRD:850 mb:9 hour fcst:
26:4998729:d=2022020218:LCDC:low cloud layer:9 hour fcst:
27:5243931:d=2022020218:LCDC:low cloud layer:6-9 hour ave fcst:
28:5491117:d=2022020218:MCDC:middle cloud layer:9 hour fcst:
29:5679383:d=2022020218:MCDC:middle cloud layer:6-9 hour ave fcst:
30:5874880:d=2022020218:HCDC:high cloud layer:9 hour fcst:
31:6089765:d=2022020218:HCDC:high cloud layer:6-9 hour ave fcst:
32:6324000:d=2022020218:PRES:low cloud bottom level:6-9 hour ave fcst:
33:6676205:d=2022020218:PRES:middle cloud bottom level:6-9 hour ave fcst:
34:6978111:d=2022020218:PRES:high cloud bottom level:6-9 hour ave fcst:
35:7345909:d=2022020218:PRES:low cloud top level:6-9 hour ave fcst:
36:7704032:d=2022020218:PRES:middle cloud top level:6-9 hour ave fcst:
37:814:d=2022020218:PRES:high cloud top level:6-9 hour ave fcst:
38:8367797:d=2022020218:PRES:tropopause:9 hour fcst:
39:8762649:d=2022020218:TMP:tropopause:9 hour fcst:
Feb 03 05:18:50  ---
Feb 03 05:18:50  Starting server
Feb 03 05:18:50  ---
Feb 03 05:18:50  ['X:\\only 4 Xplane/steamapps/common/X-Plane 
11\\Resources\\plugins\\PythonPlugins\\noaweather\\weatherServer.py', 'X:\\only 
4 Xplane/steamapps/common/X-Plane 11']
Feb 03 05:18:50  Saving Settings to X:\only 4 Xplane/steamapps/common/X-Plane 
11\Resources\plugins\PythonPlugins\noaweather\weatherServer.pkl
Feb 03 05:18:50  Server started.
Feb 03 05:18:50  Downloading part of 
https://www.aviationweather.gov/docs/metar/stations.txt with params: 
{'context': }
Feb 03 05:18:51  Downloading: 20220202_gfs.t18z.pgrb2full.0p50.f009
Feb 03 05:18:51  Downloading part of 
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009.idx
 with params: {'context': }
Feb 03 05:18:51  Updating metar stations.
Feb 03 05:18:51  Downloading part of 
https://aviationweather.gov/adds/dataserver_current/current/metars.cache.csv.gz 
with params: {'context': }
Feb 03 05:18:51  9258 metar stations updated.
Feb 03 05:18:51  Downloading: 2022020218_gfs.t18z.wafs_0p25_unblended.f12.grib2
Feb 03 05:18:51  Downloading part of 
https://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.wafs_0p25_unblended.f12.grib2
 with params: {'context': }
Feb 03 05:18:53  Downloading part of 
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
 with params: {'context': }
Feb 03 05:18:54  Downloading part of 
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
 with params: {'context': }
Feb 03 05:18:55  Downloading part of 
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
 with params: {'context': }
Feb 03 05:18:57  Downloading part of 
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
 with params: {'context': }

Re: Removing ^X in paths

[Thomas Wolff]

Am 03.02.2022 um 05:12 schrieb Dennis Heimbigner:

I am using 64bit.
And it has nothing to do misreading characters.

The ^X is described in this document: 
https://www.cygwin.com/cygwin-ug-net/using-specialnames.html,


There you will see this text:

"If you don't want or can't use UTF-8 as character set for
whatever reason, you will nevertheless be able to access the
file. How does that work? When Cygwin converts the filename from
UTF-16 to your character set, it recognizes characters which
can't be converted. If that occurs, Cygwin replaces the
non-convertible character with a special character sequence. The
sequence starts with an ASCII CAN character (hex code 0x18,
equivalent Control-X), followed by the UTF-8 representation of
the character. The result is a filename containing some ugly
looking characters. While it doesn't look nice, it is nice,
because Cygwin knows how to convert this filename back to
UTF-16. The filename will be converted using your usual
character set. However, when Cygwin recognizes an ASCII CAN
character, it skips over the ASCII CAN and handles the following
bytes as a UTF-8 character. Thus, the filename is symmetrically
converted back to UTF-16 and you can access the file."
This supports a non-UTF-8 cygwin client side, e.g. when running 
LC_ALL=de_DE mintty and you have a Chinese character in a file name.



There is no obvious good reason to continue this convention.

See above, there is good reason and no reason to drop it.

Thomas



On 2/2/2022 7:23 PM, L A Walsh wrote:

On 2022/02/02 12:40, Dennis Heimbigner wrote:

It appears that windows now supports the UTF-8 codepage.

It has since early 2000's.
I light of this, it seems time to change cygwin so it no longer adds 
those

control-x (^X)  characters in e.g. path names.

^x is ASCII.  Cygwin doesn't insert ^X characters in paths.

Perhaps you are thinking of '\' which looks like ￥ (a capital 'Y' 
with 2 horizontal lines, (Fullwidth Yen Sign  U+FFE5)...if that's the 
case, some 8-bit font

displayed that sign instead of a backslash in non-unicode locals.

Are you using a 32-bit or 64-bit version of Cygwin?  on what version 
of windows?


If you still use a 32-bit version, you might need to move to a 64-bit 
version.

I know the 32-bit version sometimes had the problem because it supported
fewer fonts and fewer characters at the same time.

You might check out your locale (if in english, try setting:
LC_CTYPE="en_US.UTF-8"
in your shell and also check that your used font has a backslash in the
0x7f position.

But in shell, ^x is usually a character to erase the whole line -- so 
it really

wouldn't do to have it in a PATH.

Hope this helps, and sorry if this is completely off base.

Linda











--
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: Removing ^X in paths

[Brian Inglis]

On 2022-02-02 21:12, Dennis Heimbigner wrote:

On 2/2/2022 7:23 PM, L A Walsh wrote:

On 2022/02/02 12:40, Dennis Heimbigner wrote:

It appears that windows now supports the UTF-8 codepage.

It has since early 2000's.
I light of this, it seems time to change cygwin so it no longer adds 
those

control-x (^X)  characters in e.g. path names.

^x is ASCII.  Cygwin doesn't insert ^X characters in paths.
Perhaps you are thinking of '\' which looks like ￥ (a capital 'Y' 
with 2 horizontal lines, (Fullwidth Yen Sign  U+FFE5)...if that's the 
case, some 8-bit font

displayed that sign instead of a backslash in non-unicode locals.
Are you using a 32-bit or 64-bit version of Cygwin?  on what version 
of windows?
If you still use a 32-bit version, you might need to move to a 64-bit 
version.

I know the 32-bit version sometimes had the problem because it supported
fewer fonts and fewer characters at the same time.
You might check out your locale (if in english, try setting:
LC_CTYPE="en_US.UTF-8"
in your shell and also check that your used font has a backslash in the
0x7f position.
But in shell, ^x is usually a character to erase the whole line -- so 
it really

wouldn't do to have it in a PATH.
Hope this helps, and sorry if this is completely off base.


> I am using 64bit.
> And it has nothing to do misreading characters.
> The ^X is described in this document:
> https://www.cygwin.com/cygwin-ug-net/using-specialnames.html,
> There you will see this text:
> "If you don't want or can't use UTF-8 as character set for
> whatever reason, you will nevertheless be able to access the
> file. How does that work? When Cygwin converts the filename from
> UTF-16 to your character set, it recognizes characters which
> can't be converted. If that occurs, Cygwin replaces the
> non-convertible character with a special character sequence. The
> sequence starts with an ASCII CAN character (hex code 0x18,
> equivalent Control-X), followed by the UTF-8 representation of
> the character. The result is a filename containing some ugly
> looking characters. While it doesn't look nice, it is nice,
> because Cygwin knows how to convert this filename back to
> UTF-16. The filename will be converted using your usual
> character set. However, when Cygwin recognizes an ASCII CAN
> character, it skips over the ASCII CAN and handles the following
> bytes as a UTF-8 character. Thus, the filename is symmetrically
> converted back to UTF-16 and you can access the file."
> There is no obvious good reason to continue this convention.

This is not a convention, it is an interoperability feature, to allow 
unsupported characters to be used in filenames, otherwise Cygwin would 
have to fail the file open in locales where those characters are 
unsupported.


I have always used ASCII, ISO-8859-1/15, or UTF-8 and have never seen a 
^X in any filename, although I have produced many other control and 
special characters in filenames by error. ;^>


If you never use a limited character set locale with filenames using 
extended character sets you will never see this either.


This feature is for those who may be importing files with names in 
extended character sets but their selected locale only supports a 
limited character set.


Some users and nationalities still prefer to use locales with limited 
character sets, perhaps because their important apps still use them, and 
they are familiar with the related keyboard mappings and font glyphs.


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
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: Log.text error

[Brian Inglis]

On 2022-02-02 21:34, Niclas Helbig wrote:

The log Text told me to send you this.
I am no Code-wizzard, so I dont really know what this means.

I dont have Surface Wind Layer and WAFS Turbulence unfortunatly.
Would really like to fix that but dont know how.


...
  0 [main] WIN32wgrib2 5128 find_fast_cwd: WARNING: Couldn't 
compute FAST_CWD pointer.  Please report this problem to

the public mailing list cygwin@cygwin.com
 328371 [main] WIN32wgrib2 5128 exception::handle: Exception: 
STATUS_STACK_OVERFLOW
 331088 [main] WIN32wgrib2 5128 open_stackdumpfile: Dumping stack trace 
to WIN32wgrib2.exe.stackdump
  0 [main] WIN32wgrib2 10104 find_fast_cwd: WARNING: Couldn't 
compute FAST_CWD pointer.  Please report this problem to

the public mailing list cygwin@cygwin.com
...

Your ancient version of Cygwin is incompatible with your version of 
Windows - please update Cygwin:


https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
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

Getting trouble in installing the apps on kindle fire first generation

[Asghar Narejo]

Hi,

hope you will be in good health

i have watched the video on you tube
https://www.youtube.com/watch?v=2d4h3U4Mogg  and tried to do the same on
but failed to install all the steps that you have shared through Youtube
video.

so therefore It's my humble request kindly help me out to resolve this
issue as my kindle is not working any google apps like youtube and other
kids games.

i will be looking forward to your help

-- 
Asghar Ali NarejoStatistical Assistant
Pakistan Bureau of Statistics, Islamabad
Mobile: +92 300 3375901, 051-9106551
E-mail ID: *asgharnar...@gmail.com *
 d...@pbs.gov.pk
Website: www.pbs.gov.pk

-- 
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: Removing ^X in paths

[L A Walsh]

On 2022/02/02 20:12, Dennis Heimbigner wrote:

I am using 64bit.
And it has nothing to do misreading characters.

The ^X is described in this document: 
https://www.cygwin.com/cygwin-ug-net/using-specialnames.html,


Wow, I've never seen such a pathname.

What's an example of a filename that cygwin displays this way?


--
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