From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32470 invoked from network); 29 Jan 2023 15:55:49 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 29 Jan 2023 15:55:49 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1675007749; b=BDht6GEqQCMa5A7uT7zNxmFHdA92Hl/JP8ZTP4ApRdKlMv5cp5Nf2SNP3GJnENsSs+H5GuCl87 8HnIVPU5U087Sh4KeeQdR8ejbMiyz8xsa/ccX2PtxK+q66e4PnfSF5EefbjdMbRNdfZFz8x8Ec cWkOLeV09IAtHgmAoEkvzgPtDBIpG8lkHqXnI1phlYioUwj+E4pYsZXbA06Wgm0qYlfp43bFnZ NQuN+nr2SIgw7KonCm9tCo6ZoL7hoqR5vACNum+foN+5GMMHc5YzQc6WTBz4xc4X6F1Nxu5RlA vbhbVSDBBEumabxt4/Eo5hpWi3rbU4XyLMZ/270rc3khdQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mta01.eastlink.ca) smtp.remote-ip=24.224.136.30; dmarc=none header.from=eastlink.ca; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1675007749; bh=25ZxPnGDvYNL8Vc7Vf+d+sYXutz4OOyH3C+Yh82MUy0=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Content-Type:DKIM-Signature; b=NoOvVdFrYCTz+npI/X2CSgC+Nx/Ws+P52w8swbVZ9J8d65ylY0T84VunXUa3flwu7hUNA4OrCl 0En2zlxWkB/xA2QcfrJa5QcWsv1v24ECtZXuuZ4oNtbLLjYAMWCymfpd/C6l/IBW43c+3ZmET2 +nEaB2JO86dGPSA9cqukGMbS4YMxYuxImprlllMtsVybKMFk0McaNTcP8e4yCa/sdcgZxVNm0h B+qlObWkp8ukkq+ZMF7MwjXGAL6rCYwGhqXu8G0BsZB2lguaG+uCKjTE75gWAI5SnB91rM0Q0Z GfsVFmxFcJWYFlh+OOPI7/AaR3JGSmvNQEy4WFnUxRBx1A==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-reply-to:From:References:To: Subject:MIME-version:Date:Message-id:Content-type:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=2VEgJ2hkIcD5MW7Z6SR1ktYjkXiYf+PeEN4OKP4+lgs=; b=f/AASgzZ9rICkpI3hiVwlYb5vs gJWgHCKy6lyyZjPrg7gi30m6poi7QyXgUIm0SNWYrHBfBeBcGBB3pdXtxvWGR520MZKAfEfJuqb7k +8Nv0tah9gQoK2gu86/TDWzaf3losXsvhnz0/xOdd8P30Eckzn7l7gJHl1ROYwYTBeAJ3aJ88effi ehueDSb74Z2vu3Kh6G/a+xy1GwDVnFatfjhBkzFe3ieaqaBMtY2cfEI7uQayoqsxYuBvlawkSLtvo MTI7KqV6g0xlPm+hUrU+nRvC0VvPu/c++nsoEFOCrqWQy0SnlEcm5mYKEhwXNqN4Bv+LZQzP0ucxL 7WG6YC3Q==; Received: by zero.zsh.org with local id 1pMA20-000BAA-5h; Sun, 29 Jan 2023 15:55:48 +0000 Authentication-Results: zsh.org; iprev=pass (mta01.eastlink.ca) smtp.remote-ip=24.224.136.30; dmarc=none header.from=eastlink.ca; arc=none Received: from mta01.eastlink.ca ([24.224.136.30]:36544) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1pMA1A-000ASO-FL; Sun, 29 Jan 2023 15:54:57 +0000 Received: from csp01.eastlink.ca ([71.7.199.166]) by mta01.eastlink.ca ([24.224.136.30]) with ESMTPS id <0RP900HZS7J0WF10@mta01.eastlink.ca> for zsh-users@zsh.org; Sun, 29 Jan 2023 11:54:55 -0400 (AST) Received: from [192.168.0.4] (host-24-207-18-108.public.eastlink.ca [24.207.18.108]) by csp01.eastlink.ca ([71.7.199.166]) with ESMTPSA id MA18pnC6f6z6sMA18pgFnT (version=TLSv1_2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256); Sun, 29 Jan 2023 11:54:55 -0400 X-Authority-Analysis: v=2.4 cv=bOzQYtyZ c=1 sm=1 tr=0 ts=63d696cf a=xN66ZtSbq5jdJYpBp7G/jQ==:117 a=xN66ZtSbq5jdJYpBp7G/jQ==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=c4xuA1BUPqXpUdeYwiUA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=20KQuk_wVIKiW9e_1w8A:9 a=qyjn4P1cXrNGrYap:21 a=_W_S_7VecoQA:10 X-Vade-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeftddgkeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecugfetuffvnffkpffmpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurheptgfkffggfgfuvfhfhfgjsegrtderredtfeejnecuhfhrohhmpeftrgihucetnhgurhgvfihsuceorhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrqeenucggtffrrghtthgvrhhnpefgtddvudehveeuhfevtdfgueetfedvhfdtheeltefhieduleeukeejjeffhfehgfenucfkphepvdegrddvtdejrddukedruddtkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvgedrvddtjedrudekrddutdekpdhhvghloheplgduledvrdduieekrddtrdegngdpmhgrihhlfhhrohhmpehrrgihrghnughrvgifshesvggrshhtlhhinhhkrdgtrgdpnhgspghrtghpthhtohepvddprhgtphhtthhopeerredprhgtphhtthhopeiishhhqdhushgvrhhsseiishhhrdhorhhgpdhgvghtqdgkihhprfgrshhsfigupehtrhhuvg X-Vade-Score: 0 X-Vade-State: 0 X-EL-AUTH: rayandrews@eastlink.ca Content-type: multipart/alternative; boundary="------------azxX90HXVyyMk1wGqgmH4NwU" Message-id: <1898f1f5-9d67-c832-c145-ee02690f4bd2@eastlink.ca> Date: Sun, 29 Jan 2023 07:54:54 -0800 MIME-version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: path PATH To: zsh-users@zsh.org References: <0dc71450-d082-93da-52f8-d4e6b97199af@eastlink.ca> <3ea702de-f818-adbb-c55b-e585f8deb10f@eastlink.ca> <1a232406-ad76-b661-496b-974ddf8e67fe@ckhb.org> <8f626e62-312f-06fa-d073-5910d1aba3ad@eastlink.ca> <4993b3f3-3b71-fb80-fd60-3e72170989f2@eastlink.ca> <562e5e2d-44ff-0402-61ff-b621edecf116@eastlink.ca> Content-language: en-US From: Ray Andrews In-reply-to: X-Seq: 28845 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: This is a multi-part message in MIME format. --------------azxX90HXVyyMk1wGqgmH4NwU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2023-01-28 20:35, Bart Schaefer wrote: > > It's the other way around. The function gave you what you want, so > there's nothing for a built-in to the shell to do. Sure, that's a design decision.  How useful does something have to be before it's  hard-coded.  Matter of judgement.  Tho I'm vocal with my opinion, at the end of the day it's not my call, nor should it be.  However a guy like you is so conformed to the status quo -- nuts, you built it -- that you no longer 'see' the defects as defects (this presuming I'll right when in fact I am often wrong). Where a guy like me can be useful is in providing a fresh view of things.  I advocate for spelling reform.  Folks who's spelling is perfect say that spelling reform isn't needed. > If NO function could give you what you wanted, that's a different > question. E.g., it's a valid point that a parameter declared with > "typeset -E" could be more accurately described by $parameters / > ${(t)var}, or that justification width could be more obviously > obtainable than just "typeset +m", That's another interesting question.  IMHO core functionality is not -- or not hugely -- concerned with appearance -- the individual tarts things up as he sees fit -- but *complete* information is a core function.  OTOH, a justification option would be very nice -- saves me the trouble.  But, for example, I'd put spaces around the equal signs cuz it then breaks the output into logical words and thus makes it very much easier to, say, columnize the display. > or even that the documentation > could do a better job of relating ${(t)var} to the options of > "typeset" (I've submitted a patch for that last, incidentally). In that case my opinion is that the 'Parameters' section of the manual should tell the whole story vs. the information being attached to individual commands, since there are several commands -- not to mention ${(t)...} -- that have a duplicated use/reference to the attributes; so they should all refer back to Mother.  IOW, the fact that parameters have attributes is a fundamental feature of the shell irrespective of any particular command, not an incidental collection of details pertaining to this command or that command.  That could be said better. In the crudest, outline form, add something like the 'help' for my function: 15.1 Description A parameter has a name, a value, and a number of attributes. A name may be any sequence of alphanumeric characters and underscores, or the single characters ‘*’, ‘@’, ‘#’, ‘?’, ‘-’, ‘$’, or ‘!’. A parameter whose name begins with an alphanumeric or underscore is also referred to as a /variable/. The attributes of a parameter determine the /type/ of its value, often referred to as the parameter type or variable type, and also control other processing that may be applied to the value when it is referenced. The value type may be a /scalar/ (a string, an integer, or a floating point number), an array (indexed numerically), or an /associative/ array (an unordered set of name-value pairs, indexed by name, also referred to as a /hash/). Here's a complete list of the types and the attributes ( with their single-letter designations as used in various commands [ maybe not but .... ] ): TYPES: S: An ordinary scalar (not an integer or float). I: An integer. F: A float ('typeset -F:' decimal display or 'typeset -E': scientific display). A: A normal array. H: An associative array or 'association' or 'hash' (always 'hideval' as well). ATTRIBUTES: e: The variable has been exported to the enironment and is thus persistent within that terminal -- it will be inherited by subshells. l: The variable is local to the running function. t: The variable is 'tied' to another variable. s: The variable is special to the shell. r: The variable is read-only (this often goes with 'special'). v: 'hideval': the value of the variable will be hidden -- there are things we really don't want to see, like lists of color codes.  This tends to go with 'special' and 'hide'. h: Hide: Used with 'special' ?? u: Unique: ?? ?: Undefined: For autoloaded parameters not yet loaded (whatever that means). These types and attributes will now be discussed in detail: ... back to text. BTW, that section of the manual is very well written, almost literate, and technical writing hardly ever is, tho I do wish it was complete. BTW am I mistaken that 'hideval' is not discussed anywhere? --------------azxX90HXVyyMk1wGqgmH4NwU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 2023-01-28 20:35, Bart Schaefer wrote:

It's the other way around.  The function gave you what you want, so
there's nothing for a built-in to the shell to do.
Sure, that's a design decision.  How useful does something have to be before it's  hard-coded.  Matter of judgement.  Tho I'm vocal with my opinion, at the end of the day it's not my call, nor should it be.  However a guy like you is so conformed to the status quo -- nuts, you built it -- that you no longer 'see' the defects as defects (this presuming I'll right when in fact I am often wrong).  Where a guy like me can be useful is in providing a fresh view of things.  I advocate for spelling reform.  Folks who's spelling is perfect say that spelling reform isn't needed.  
If NO function could give you what you wanted, that's a different
question.  E.g., it's a valid point that a parameter declared with
"typeset -E" could be more accurately described by $parameters /
${(t)var}, or that justification width could be more obviously
obtainable than just "typeset +m",
That's another interesting question.  IMHO core functionality is not -- or not hugely -- concerned with appearance -- the individual tarts things up as he sees fit -- but *complete* information is a core function.  OTOH, a justification option would be very nice -- saves me the trouble.  But, for example, I'd put spaces around the equal signs cuz it then breaks the output into logical words and thus makes it very much easier to, say, columnize the display.  
 or even that the documentation
could do a better job of relating ${(t)var} to the options of
"typeset" (I've submitted a patch for that last, incidentally).

In that case my opinion is that the 'Parameters' section of the manual should tell the whole story vs. the information being attached to individual commands, since there are several commands -- not to mention ${(t)...} -- that have a duplicated use/reference to the attributes; so they should all refer back to Mother.  IOW, the fact that parameters have attributes is a fundamental feature of the shell irrespective of any particular command, not an incidental collection of details pertaining to this command or that command.  That could be said better. 

In the crudest, outline form, add something like the 'help' for my function:

15.1 Description

A parameter has a name, a value, and a number of attributes. A name may be any sequence of alphanumeric characters and underscores, or the single characters ‘*’, ‘@’, ‘#’, ‘?’, ‘-’, ‘$’, or ‘!’. A parameter whose name begins with an alphanumeric or underscore is also referred to as a variable.

The attributes of a parameter determine the type of its value, often referred to as the parameter type or variable type, and also control other processing that may be applied to the value when it is referenced. The value type may be a scalar (a string, an integer, or a floating point number), an array (indexed numerically), or an associative array (an unordered set of name-value pairs, indexed by name, also referred to as a hash).

Here's a complete list of the types and the attributes ( with their single-letter designations as used in various commands [ maybe not but .... ] ):

TYPES:

S: An ordinary scalar (not an integer or float).
I: An integer.
F: A float ('typeset -F:' decimal display or 'typeset -E': scientific display).
A: A normal array.
H: An associative array or 'association' or 'hash' (always 'hideval' as well).

ATTRIBUTES:

e: The variable has been exported to the enironment and is thus persistent within that terminal -- it will be inherited by subshells.
l: The variable is local to the running function.
t: The variable is 'tied' to another variable.
s: The variable is special to the shell.
r: The variable is read-only (this often goes with 'special').
v: 'hideval': the value of the variable will be hidden -- there are things we really don't want to see, like lists of color codes.  This tends to go with 'special' and 'hide'.
h: Hide: Used with 'special' ??
u: Unique: ??
?: Undefined: For autoloaded parameters not yet loaded (whatever that means).

These types and attributes will now be discussed in detail:

... back to text. 


BTW, that section of the manual is very well written, almost literate, and technical writing hardly ever is, tho I do wish it was complete.  

BTW am I mistaken that 'hideval' is not discussed anywhere? 


--------------azxX90HXVyyMk1wGqgmH4NwU--