Definition at line 9 of file Relation.php.
Create a new relation instance.
- Parameters
-
| \Illuminate\Database\Eloquent\Builder | $query | |
| \Illuminate\Database\Eloquent\Model | $parent | |
- Returns
- void
Definition at line 46 of file Relation.php.
| __call |
( |
|
$method, |
|
|
|
$parameters |
|
) |
| |
Handle dynamic method calls to the relationship.
- Parameters
-
| string | $method | |
| array | $parameters | |
- Returns
- mixed
Definition at line 281 of file Relation.php.
Set the base constraints on the relation query.
- Returns
- void
| addEagerConstraints |
( |
array |
$models | ) |
|
|
abstract |
Set the constraints for an eager load of the relation.
- Parameters
-
- Returns
- void
Get the name of the "created at" column.
- Returns
- string
Definition at line 238 of file Relation.php.
Get the relationship for eager loading.
- Returns
Definition at line 101 of file Relation.php.
| getKeys |
( |
array |
$models, |
|
|
|
$key = null |
|
) |
| |
|
protected |
Get all of the primary keys for an array of models.
- Parameters
-
- Returns
- array
Definition at line 174 of file Relation.php.
Get the parent model of the relation.
- Returns
Definition at line 208 of file Relation.php.
| getQualifiedParentKeyName |
( |
| ) |
|
Get the fully qualified parent key name.
- Returns
- string
Definition at line 218 of file Relation.php.
Get the underlying query for the relation.
- Returns
Definition at line 188 of file Relation.php.
Get the related model of the relation.
- Returns
Definition at line 228 of file Relation.php.
Add the constraints for a relationship count query.
- Parameters
-
| \Illuminate\Database\Eloquent\Builder | $query | |
| \Illuminate\Database\Eloquent\Builder | $parent | |
- Returns
Definition at line 136 of file Relation.php.
Get the results of the relationship.
- Returns
- mixed
| initRelation |
( |
array |
$models, |
|
|
|
$relation |
|
) |
| |
|
abstract |
Initialize the relation on a set of models.
- Parameters
-
| array | $models | |
| string | $relation | |
- Returns
- array
| match |
( |
array |
$models, |
|
|
Collection |
$results, |
|
|
|
$relation |
|
) |
| |
|
abstract |
Match the eagerly loaded results to their parents.
- Parameters
-
| array | $models | |
| \Illuminate\Database\Eloquent\Collection | $results | |
| string | $relation | |
- Returns
- array
| static noConstraints |
( |
Closure |
$callback | ) |
|
|
static |
Run a callback with constraints disabled on the relation.
- Parameters
-
- Returns
- mixed
Definition at line 151 of file Relation.php.
| rawUpdate |
( |
array |
$attributes = array() | ) |
|
Run a raw update against the base query.
- Parameters
-
- Returns
- int
Definition at line 124 of file Relation.php.
Get the name of the related model's "updated at" column.
- Returns
- string
Definition at line 258 of file Relation.php.
Touch all of the related models for the relationship.
- Returns
- void
Definition at line 111 of file Relation.php.
Get the name of the "updated at" column.
- Returns
- string
Definition at line 248 of file Relation.php.
Wrap the given value with the parent query's grammar.
- Parameters
-
- Returns
- string
Definition at line 269 of file Relation.php.
The documentation for this class was generated from the following file:
- vendor/laravel/framework/src/Illuminate/Database/Eloquent/Relations/Relation.php


Golden Rectangle Calculator
The golden rectangle is a rectangle whose sides are in the golden
ratio. The golden ratio has a value of approximately 1.618.
If 'a' is width and 'a+b' is length of golden rectangle
then,\[\frac{a+b}{b}=\frac{a}{b}\]
Enter any 1 field


Contains classes commonly used by other classes.
Related Documentation
For overviews, tutorials, examples, guides, and tool documentation, please see:
Globus


Intuition.dev
Shop
0
Next
Shipping address
×
Please, enter your address
Name
Company
address1
address2
city
state_code
country_code
zip
Proceed to checkout


Pinglabs is a small performance management company that focused on providing companies information about employee engagement and employee goals. We were tasked with redesigning their dashboard. Our goal was to create a professional, organized, and clean dashboard that would lead to new business for our client.
While Pinglabs customers are a fan of the questions Pinglabs sends out and the ease of responding to them by email, the current dashboard to view the data is poor. Matthew Cholerton, the owner of Pinglabs, describes the dashboard as “Unprofessional” in our first meeting with him. He also said that he was embarrassed to show potential clients the dashboard due to it’s quality. It was in dire need of a clean, professional, and organized redesign. Here is a screenshot of the previous pinglabs:
The previous version of pinglabs had little visual style, stretched for multiple page scrolls, and had no ryhme or reasoning to it's ordering. These all needed to change.
Here are some highlights of our research:
We interviewed 9 managers using pinglabs with the following script:
From our user interviews, we created a large affinity diagram to get a sense of the trends in our user research:
Some of the biggest categories, in descending order, where:
From our affinity diagram, we next moved on to creating persona’s.
For our design phase of the project, we tasked each person with coming up with multiple designs for different sections of the project. We then came back together and made group decisions about the best design for every part of the dashboard. I was tasked with designing the user interface, the outliers page, and the responses page.
Here's the responses tab:
Here's the outliers tab:
Here is the response tab of the dashboard:
Here is the outliers tab of the dashboard:
For the response tab, the focus was on determing the right order and correct way to display each graph. I wanted there to be more actionable data, so buttons were added to the Employees feedback and Employees who haven't answered sections. Here is the responses tab mockup:
For the outlers, I tried to keep a very consistent visual feel. The graphs are ordered by importance, and each has a line representing the average so you can see if the lowest answer is truly an outlier. Here is the outliers tab mockup:
This was a very difficult and rewarding project for me. None of my team had experience working on or with a dashboard of information, and only one of us had ever used a performance management system before. We had to spend a lot of time researching dashboards and data visualization, and the product would certainly be better if we had access to a data professional. The team dynamic issues addressed above also added another layer of problems that while not fun, were interesting to learn about. All things considered, my team worked really hard and our client glowed about the final product.


This example works in Firefox 4+ and Chrome. Note that Firefox does not allow local files to access indexedDB, so you'll need to run this example through a web server to get it to work on Firefox (Chrome does not have this restriction).
indexedDB


Updating the status of an item is easy. First, click on the title of the category below to expand it.
Next, select an option from an item's status menu.
Nice! You'll be an expert in no time.


The logarithm function officially inverts a complex exponential on paper but not numerically:
The graph above is the real part of
\[ -i \log[ \exp( ix ) ] \]A straightforward inversion says this should be equal to \(x\), but since \(\exp(2 \pi i)=1\) the numerical evaluation is in practice modulus \(2 \pi i\). This is one example of differences to keep in mind between formal mathematics and numerical implementation.
This example requires the higher-level mathematics of Math.
Complete code for this example:


Barley and Red Oak are being made by Plain.
You can feel free to use this template in anyway you want. Give attribution, don’t give attribution, it is up to you.


Class LocatorList_t, a Locator_t vector that doesn't avoid duplicates.
More...
#include <Locator.h>
Class LocatorList_t, a Locator_t vector that doesn't avoid duplicates.
◆ LocatorList_t() [1/3]
◆ ~LocatorList_t()
◆ LocatorList_t() [2/3]
◆ LocatorList_t() [3/3]
◆ begin() [1/2]
◆ begin() [2/2]
◆ clear()
| RTPS_DllAPI void clear |
( |
| ) |
|
|
inline |
◆ contains()
| RTPS_DllAPI bool contains |
( |
const Locator_t & |
loc | ) |
|
|
inline |
◆ empty()
| RTPS_DllAPI bool empty |
( |
| ) |
|
|
inline |
◆ end() [1/2]
◆ end() [2/2]
◆ erase()
| RTPS_DllAPI void erase |
( |
const Locator_t & |
loc | ) |
|
|
inline |
◆ isValid()
| RTPS_DllAPI bool isValid |
( |
| ) |
|
|
inline |
◆ operator=() [1/2]
◆ operator=() [2/2]
◆ operator==()
| RTPS_DllAPI bool operator== |
( |
const LocatorList_t & |
locator_list | ) |
const |
|
inline |
◆ push_back() [1/2]
| RTPS_DllAPI void push_back |
( |
const Locator_t & |
loc | ) |
|
|
inline |
◆ push_back() [2/2]
◆ reserve()
| RTPS_DllAPI void reserve |
( |
size_t |
num | ) |
|
|
inline |
◆ resize()
| RTPS_DllAPI void resize |
( |
size_t |
num | ) |
|
|
inline |
◆ size()
| RTPS_DllAPI size_t size |
( |
| ) |
|
|
inline |
◆ swap()
◆ operator<<
| std::ostream& operator<< |
( |
std::ostream & |
output, |
|
|
const LocatorList_t & |
loc |
|
) |
| |
|
friend |
The documentation for this class was generated from the following file:
- /home/ricardo/workspace/curro/eProsima/desarrollo/proyectos/fastrtps/include/fastrtps/rtps/common/Locator.h


This file lists and describes the Cisco VQE system messages and recovery procedures. The VQE software writes these messages to the following locations:
Not all system messages indicate problems with VQE. Some messages are purely informational, while others may help diagnose problems with communications links or the operating system (for example, file permission problems). Only critical messages are displayed on the CDE110 console.
For information on VQE-S AMT and VCPT logging output, see the Cisco CDA Visual Quality Experience Application User Guide.
System messages are structured as follows:
FACILITY-SEVERITY-MNEMONIC: Message-text
| Code | VQE Facility |
| STUN_SERVER | STUN Server (VQE-S) |
| VQES_CP VQE-S | VQE-S Control Plane |
| VQES_DP_CLIENT | VQE-S Data Plane Client |
| VQES_DP | VQE-S Data Plane |
| VQES_MLB_Client | VQE-S Multicast Load Balancer Client |
| VQES_MLB | VQE-S Multicast Load Balancer |
| VQES_PM | VQE-S Process Monitor |
| VQE_CFGTOOL | VQE Configuration Tool (vqe_cfgtool command) |
| VQE_CFG | VQE channel configuration |
| VQE_UTILS | VQE Utilities |
| VQE_RPC | VQE-S Remote Procedure Call facility |
| VQE_RTP | VQE Real-Time Transport Protocol (Many of these messages are related to RTP Control Protocol (RTCP)). |
| VQE_RTSP | VQE Real Time Streaming Protocol (VCDS) |
| Representation | Type of Information |
| [chars] or [char] | Character string |
| [dec] | Decimal |
| [hex] | Hexadecimal integer |
| [int] | Integer |
| [num] | Number |
The following is an example of a VQE system message:
VQES_CP-3-CP_CHANNEL_DELETE_ERR: Failed to delete a channel due to [chars]
In the Recommended Actions of the system messages, certain recovery procedures that VQE users should perform are referred to numerous times. The following table provides references to where you can find more information on these recovery procedures.
Note: In the following table, all references are to sections found in the Cisco CDA Visual Quality Experience Application User Guide


|
EOS.IO
DAWN2.0.1
|
Classes | |
| struct | close |
| Action to close new game. More... | |
| struct | create |
| Action to create new game. More... | |
| struct | game |
| Data structure to hold game information. More... | |
| struct | move |
| Action to make movement. More... | |
| struct | movement |
| Data structure for movement. More... | |
| struct | restart |
| Action to restart new game. More... | |
Typedefs | |
| using | Games = eosio::table< N(tic.tac.toe), N(tic.tac.toe), N(games), game, uint64_t > |
| table to store list of games More... | |
Functions | |
| bool | is_empty_cell (const uint8_t &cell) |
| Check if cell is empty. More... | |
| bool | is_valid_movement (const movement &mvt, const game &game_for_movement) |
| Check for valid movement Movement is considered valid if it is inside the board and done on empty cell. More... | |
| account_name | get_winner (const game ¤t_game) |
| Get winner of the game Winner of the game is the first player who made three consecutive aligned movement. More... | |
| void | apply_create (const create &c) |
| Apply create action. More... | |
| void | apply_restart (const restart &r) |
| Apply restart action. More... | |
| void | apply_close (const close &c) |
| Apply close action. More... | |
| void | apply_move (const move &m) |
| Apply move action. More... | |
| using tic_tac_toe::Games = typedef eosio::table<N(tic.tac.toe),N(tic.tac.toe),N(games),game,uint64_t> |
| void tic_tac_toe::apply_close | ( | const close & | c | ) |
| close | - action to be applied |
| void tic_tac_toe::apply_create | ( | const create & | c | ) |
| create | - action to be applied |
| void tic_tac_toe::apply_move | ( | const move & | m | ) |
| move | - action to be applied |
| void tic_tac_toe::apply_restart | ( | const restart & | r | ) |
| restart | - action to be applied |
| account_name tic_tac_toe::get_winner | ( | const game & | current_game | ) |
| game | - the game which we want to determine the winner of |
| bool tic_tac_toe::is_empty_cell | ( | const uint8_t & | cell | ) |
| cell | - value of the cell (should be either 0, 1, or 2) |


{{ 'Click here to register an product' | translate}}.
{{ 'To know what an product is, click on the question mark icon' | translate}}.


|
Panda3D
|
An input stream object that uses OpenSSL to encrypt data to another destination stream on-the-fly. More...
Public Member Functions | |
| __init__ () | |
| __init__ (Ostream dest, bool owns_dest, str password) | |
| OEncryptStream | close () |
| Resets the EncryptStream to empty, but does not actually close the dest ostream unless owns_dest was true. More... | |
| OEncryptStream | open (Ostream dest, bool owns_dest, str password) |
| setAlgorithm (str algorithm) | |
| Specifies the encryption algorithm that should be used for future calls to open(). More... | |
| setIterationCount (int iteration_count) | |
| Specifies the number of times to repeatedly hash the key before writing it to the stream in future calls to open(). More... | |
| setKeyLength (int key_length) | |
| Specifies the length of the key, in bits, that should be used to encrypt the stream in future calls to open(). More... | |
| Public Member Functions inherited from Ostream | |
| flush () | |
| put (char c) | |
| seekp (Streamoff off, IosBase::Seekdir dir) | |
| seekp (Streamoff pos) | |
| Streamoff | tellp () |
| Public Member Functions inherited from BasicIosChar | |
| bool | bad () |
| clear () | |
| bool | eof () |
| bool | fail () |
| bool | good () |
Public Attributes | |
| const String | algorithm |
| Returns the encryption algorithm that was read from the stream. More... | |
| int | iteration_count |
| Returns the value that was was read from the stream. More... | |
| int | key_length |
| Returns the encryption key length, in bits, that was read from the stream. More... | |
Additional Inherited Members | |
| Public Types inherited from IosBase | |
| enum | Iostate |
| enum | Openmode |
| enum | Seekdir { beg = 0, cur = 1, end = 2 } |
An input stream object that uses OpenSSL to encrypt data to another destination stream on-the-fly.
Attach an OEncryptStream to an existing ostream that will accept encrypted data, and write your unencrypted source data to the OEncryptStream.
Seeking is not supported.
| __init__ | ( | ) |
| __init__ | ( | Ostream | dest, |
| bool | owns_dest, | ||
| str | password | ||
| ) |
| OEncryptStream close | ( | ) |
Resets the EncryptStream to empty, but does not actually close the dest ostream unless owns_dest was true.
| OEncryptStream open | ( | Ostream | dest, |
| bool | owns_dest, | ||
| str | password | ||
| ) |
| setAlgorithm | ( | str | algorithm | ) |
Specifies the encryption algorithm that should be used for future calls to open().
The default is whatever is specified by the encryption-algorithm config variable. The complete set of available algorithms is defined by the current version of OpenSSL.
If an invalid algorithm is specified, there is no immediate error return code, but open() will fail.
| setIterationCount | ( | int | iteration_count | ) |
Specifies the number of times to repeatedly hash the key before writing it to the stream in future calls to open().
Its purpose is to make it computationally more expensive for an attacker to search the key space exhaustively. This should be a multiple of 1,000 and should not exceed about 65 million; the value 0 indicates just one application of the hashing algorithm.
The default is whatever is specified by the encryption-iteration-count config variable.
| setKeyLength | ( | int | key_length | ) |
Specifies the length of the key, in bits, that should be used to encrypt the stream in future calls to open().
The default is whatever is specified by the encryption-key-length config variable.
If an invalid key_length for the chosen algorithm is specified, there is no immediate error return code, but open() will fail.
| const String algorithm |
Returns the encryption algorithm that was read from the stream.
| int iteration_count |
Returns the value that was was read from the stream.
| int key_length |
Returns the encryption key length, in bits, that was read from the stream.


This page contains examples of the different fields provided by Schema Form in Horizon. The Schema
and Form
sections below can be edited inline to customise the form output. For further documentation on Schema Form, see http://schemaform.io/.
{$ ctrl.prettyModelData() $}
Use the schema to describe the data model and valid input patterns. A schema is always JSON. NOTE: A schema element is not needed for items that have no data model, like sections and fieldsets.
Use the form to set titles, descriptions and choose specific UI element types for each schema item. In the form builder, the form must be JSON, but you can use JavaScript in production code, such as gettext
for translation.


行业报告智能辅助平台
数据资源
数据列表
数据上传
图表可视
基本图表:
Pie:饼图
Polar:极坐标系
Radar:雷达图
Sankey:桑基图
Graph:关系图
WordCloud:词云图
直角坐标系图表:
Bar:柱状图/条形图
Line:折线/面积图
Scatter:散点图
树型图表:
Tree:树图
Blank Page
地理图表:
Blank Page
Blank Page
报告呈现
模板首页
3+
Alerts Center
December 12, 2019
A new monthly report is ready to download!
December 7, 2019
$290.29 has been deposited into your account!
December 2, 2019
Spending Alert: We've noticed unusually high spending for your account.
Show All Alerts
7
Message Center
Hi there! I am wondering if you can help me with a problem I've been having.
Emily Fowler · 58m
I have the photos that you ordered last month, how would you like them sent to you?
Jae Chun · 1d
Last month's report looks great, I am very happy with the progress so far, keep up the good work!
Morgan Alvarez · 2d
Am I a good boy? The reason I ask is because someone told me that people say this to all dogs, even if they aren't good...
Chicken the Dog · 2w
Read More Messages
Valerie Luna
Profile
Settings
Activity Log
Logout
Line 折线/面积图
刷新图表
图表
数据域
全局配置项
标题
副标题
标题水平位置
靠左
居中
靠右
标题竖直位置
靠上
居中
靠下
图例水平位置
靠右
靠左
居中
图例竖直位置
靠上
居中
靠下
图例朝向
水平
竖直
提交
x轴设置
是否翻转
不翻转
翻转
是否平滑曲线
不平滑
平滑
提交
数据
数据导入模板下载
文件:
提交
Ready to Leave?
×
Select "Logout" below if you are ready to end your current session.


What is Virtualization?
Virtualization eliminates the need for additional and costly hardware. It enables developers, using different virtual machines, to run multiple operating systems. Developers are finally able to step away from in-house hardware assets. Virtualization also allows for simple recovery and maintenance if anything were to ever fail.
Even with its many perks, virtualization does have some down sides. Users can sometimes experience unstable performance or long boot up times. This is due in part to guest OS is running on top of the host OS which takes up things like processor power and memory.
To find out even more about virtualization, click here.


getnetworkinfo - Okcash RPC
getnetworkinfo Returns an object containing various state info regarding P2P networking. Result: { "version": xxxxx, (numeric) the server version "subversion": "/oktoshi:x.x.x/", (string) the server subversion string "protocolversion": xxxxx, (numeric) the protocol version "localservices": "xxxxxxxxxxxxxxxx", (string) the services we offer to the network "timeoffset": xxxxx, (numeric) the time offset "connections": xxxxx, (numeric) the number of connections "networks": [ (array) information per network { "name": "xxx", (string) network (ipv4, ipv6 or onion) "limited": true|false, (boolean) is the network limited using -onlynet? "reachable": true|false, (boolean) is the network reachable? "proxy": "host:port" (string) the proxy that is used for this network, or empty if none } ,... ], "localaddresses": [ (array) list of local addresses { "address": "xxxx", (string) network address "port": xxx, (numeric) network port "score": xxx (numeric) relative score } ,... ] "warnings": "..." (string) any network warnings } Examples: > okcashd getnetworkinfo > curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getnetworkinfo", "params": [] }' -H 'content-type: text/plain;' http://<IP_ADDRESS>:6969/
Okcash Core RPC documentation.
Okcash version: <IP_ADDRESS>
OK RPC docs at:Github
Rawtransactions
Smsg
Wallet
addmultisigaddress
backupwallet
clearwallettransactions
dumpprivkey
dumpwallet
encryptwallet
getaccount
getaccountaddress
getaddressesbyaccount
getbalance
getnewaddress
getnewstealthaddress
getreceivedbyaccount
getreceivedbyaddress
getstakinginfo
gettransaction
importprivkey
importstealthaddress
importwallet
keypoolrefill
listaccounts
listaddressgroupings
listreceivedbyaccount
listreceivedbyaddress
listsinceblock
liststealthaddresses
listtransactions
listunspent
move
reservebalance
rewindchain
sendmany
sendtoaddress
setaccount
settxfee
signmessage
walletlock
walletpassphrase
walletpassphrasechange
backupwallet
clearwallettransactions
dumpprivkey
dumpwallet
encryptwallet
getaccount
getaccountaddress
getaddressesbyaccount
getbalance
getnewaddress
getnewstealthaddress
getreceivedbyaccount
getreceivedbyaddress
getstakinginfo
gettransaction
importprivkey
importstealthaddress
importwallet
keypoolrefill
listaccounts
listaddressgroupings
listreceivedbyaccount
listreceivedbyaddress
listsinceblock
liststealthaddresses
listtransactions
listunspent
move
reservebalance
rewindchain
sendmany
sendtoaddress
setaccount
settxfee
signmessage
walletlock
walletpassphrase
walletpassphrasechange


| World Cities click on city to see details |
| {{city.cityName}} |
| Wind Speed | Average Temperature |
| {{weatherData.windSpeed}} | {{weatherData.avgTemp | number : 2}} |
Click the row above to see 24hr forecast
| Time of day | Temperature |
| {{forecast.evtTime}} | {{forecast.evtTemp}} |


CREATE [ OR REPLACE ] [ PROCEDURAL ] LANGUAGE name CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE name HANDLER call_handler [ INLINE inline_handler ] [ VALIDATOR valfunction ]
CREATE LANGUAGE registers a new procedural language with a PostgreSQL database. Subsequently, functions and trigger procedures can be defined in this new language.
CREATE LANGUAGE effectively associates the language name with handler function(s) that are responsible for executing functions written in the language. Refer to Chapter 49 for more information about language handlers.
There are two forms of the CREATE LANGUAGE command. In the first form, the user supplies just the name of the desired language, and the PostgreSQL server consults the pg_pltemplate system catalog to determine the correct parameters. In the second form, the user supplies the language parameters along with the language name. The second form can be used to create a language that is not defined in pg_pltemplate, but this approach is considered obsolescent.
When the server finds an entry in the pg_pltemplate catalog for the given language name, it will use the catalog data even if the command includes language parameters. This behavior simplifies loading of old dump files, which are likely to contain out-of-date information about language support functions.
Ordinarily, the user must have the PostgreSQL superuser privilege to register a new language. However, the owner of a database can register a new language within that database if the language is listed in the pg_pltemplate catalog and is marked as allowed to be created by database owners (tmpldbacreate is true). The default is that trusted languages can be created by database owners, but this can be adjusted by superusers by modifying the contents of pg_pltemplate. The creator of a language becomes its owner and can later drop it, rename it, or assign it to a new owner.
CREATE OR REPLACE LANGUAGE will either create a new language, or replace an existing definition. If the language already exists, its parameters are updated according to the values specified or taken from pg_pltemplate, but the language's ownership and permissions settings do not change, and any existing functions written in the language are assumed to still be valid. In addition to the normal privilege requirements for creating a language, the user must be superuser or owner of the existing language. The REPLACE case is mainly meant to be used to ensure that the language exists. If the language has a pg_pltemplate entry then REPLACE will not actually change anything about an existing definition, except in the unusual case where the pg_pltemplate entry has been modified since the language was created.
TRUSTED specifies that the language does not grant access to data that the user would not otherwise have. If this key word is omitted when registering the language, only users with the PostgreSQL superuser privilege can use this language to create new functions.
This is a noise word.
The name of the new procedural language. The language name is case insensitive. The name must be unique among the languages in the database.
For backward compatibility, the name can be enclosed by single quotes.
call_handler is the name of a previously registered function that will be called to execute the procedural language's functions. The call handler for a procedural language must be written in a compiled language such as C with version 1 call convention and registered with PostgreSQL as a function taking no arguments and returning the language_handler type, a placeholder type that is simply used to identify the function as a call handler.
inline_handler is the name of a previously registered function that will be called to execute an anonymous code block (DO command) in this language. If no inline_handler function is specified, the language does not support anonymous code blocks. The handler function must take one argument of type internal, which will be the DO command's internal representation, and it will typically return void. The return value of the handler is ignored.
valfunction is the name of a previously registered function that will be called when a new function in the language is created, to validate the new function. If no validator function is specified, then a new function will not be checked when it is created. The validator function must take one argument of type oid, which will be the OID of the to-be-created function, and will typically return void.
A validator function would typically inspect the function body
for syntactical correctness, but it can also look at other
properties of the function, for example if the language cannot
handle certain argument types. To signal an error, the
validator function should use the ereport()
function. The return value of the function is ignored.
The TRUSTED option and the support function name(s) are ignored if the server has an entry for the specified language name in pg_pltemplate.
The createlang program is a simple wrapper around the CREATE LANGUAGE command. It eases installation of procedural languages from the shell command line.
Use DROP LANGUAGE, or better yet the droplang program, to drop procedural languages.
The system catalog pg_language
(see Section 45.24) records information about the
currently installed languages. Also, createlang
has an option to list the installed languages.
To create functions in a procedural language, a user must have the USAGE privilege for the language. By default, USAGE is granted to PUBLIC (i.e., everyone) for trusted languages. This can be revoked if desired.
Procedural languages are local to individual databases. However, a language can be installed into the template1 database, which will cause it to be available automatically in all subsequently-created databases.
The call handler function, the inline handler function (if any), and the validator function (if any) must already exist if the server does not have an entry for the language in pg_pltemplate. But when there is an entry, the functions need not already exist; they will be automatically defined if not present in the database. (This might result in CREATE LANGUAGE failing, if the shared library that implements the language is not available in the installation.)
In PostgreSQL versions before 7.3, it was necessary to declare handler functions as returning the placeholder type opaque, rather than language_handler. To support loading of old dump files, CREATE LANGUAGE will accept a function declared as returning opaque, but it will issue a notice and change the function's declared return type to language_handler.
The preferred way of creating any of the standard procedural languages is just:
CREATE LANGUAGE plperl;
For a language not known in the pg_pltemplate catalog, a sequence such as this is needed:
CREATE FUNCTION plsample_call_handler() RETURNS language_handler AS '$libdir/plsample' LANGUAGE C; CREATE LANGUAGE plsample HANDLER plsample_call_handler;


health climate change Health vulnerability Canada public local assessment Ontario collab: Climate Simcoe Change ON, community impacts support Muskoka adaptation Public data key capacity adaptive mitigation {border-style Assessment Research disease understanding unit SMDHU Vulnerability identified px;} #ffffff;} (e.g., District research Toronto, Unit current increase ... Care Lyme assessments climate-sensitive internal identify Ministry actions future process program Canadian action agency Long-Term environmental human issue municipal organizations partners planning potential Statistics identification informant required results staff units vulnerabilities (accessed Available Current analysis assessment, challenges extreme need online: population projected provincial resources supported surveillance tick Box Environment Future Impacts Muskoka. Population Printer Queen’s associated change. completed completion ensure focus groups increased individuals interviews knowledge populations precipitation px; related supporting {font-family Adaptive Capacity Ixodes Muskoka, Ottawa, access areas change, context creation external font-size food highlighted including international national needs outcomes partnerships priority projections qualitative specific stakeholder temperature vulnerable Adaptation Barrie, CCAP Data Environ. Int. Local Results York activities addition, agencies climate-related collaboration communities development double; engagement framework global health, programming provided range scapularis stakeholders ticks weather ./s--- Berry Cancer Council Environmental Government New Policy Projections Scoping address approach assessment. available border-color border-width change: collection completing context. engaged enhanced geographic guidelines information level measures multiple municipalities policy primary programs regional scope sensitivity solid; urban used {font-style {font-weight (s) (s), Action Building Census Climate: Communicating Ebi Figure Global Health, Human Identification IntelliHEALTH K.L. Key Lancet Medical National Ontario, Paterson Perspect. Phase Program Report Social USA University Vulnerabilities World ability action. adaption allowed bold broader changes changing committee complex conducted connections consideration courier; critical currently decrease describes determinants em; events expected expertise explored gaps health. impact impacts, included individual lack low policies presence projection pt;} relevant residents resilience resiliency response sampling shown stakeholders. steering step study surrounding temperatures vector-borne work


{{ url }}
Get url
Remove
Add match
Systems:
Bet:
Check
Matches
Index
Name
Coef
{{final.index}}
{{final.name}}
{{final.k}}
Total bet: {{combinations.length * bet}}
Combinations
Matches
Coef
Winning
{{totalWinning}}
{{ index }}
{{cmb.k}}
{{cmb.winning}}
Result
{{final.name}}
See winnings
You won: {{ won }}


This is the Cookie Policy
As is common practice with almost all professional websites this site uses cookies, which are tiny files that are downloaded to your computer, to improve your experience. This page describes what information they gather, how we use it and why we sometimes need to store these cookies. We will also share how you can prevent these cookies from being stored however this may downgrade or 'break' certain elements of the sites functionality.
For more general information on cookies, please read "What Are Cookies".
We use cookies for a variety of reasons detailed below. Unfortunately in most cases there are no industry standard options for disabling cookies without completely disabling the functionality and features they add to this site. It is recommended that you leave on all cookies if you are not sure whether you need them or not in case they are used to provide a service that you use.
You can prevent the setting of cookies by adjusting the settings on your browser (see your browser Help for how to do this). Be aware that disabling cookies will affect the functionality of this and many other websites that you visit. Disabling cookies will usually result in also disabling certain functionality and features of the this site. Therefore it is recommended that you do not disable cookies.
Forms related cookies
When you submit data to through a form such as those found on contact pages or comment forms cookies may be set to remember your user details for future correspondence.
In some special cases we also use cookies provided by trusted third parties. The following section details which third party cookies you might encounter through this site.
This site uses Google Analytics which is one of the most widespread and trusted analytics solution on the web for helping us to understand how you use the site and ways that we can improve your experience. These cookies may track things such as how long you spend on the site and the pages that you visit so we can continue to produce engaging content.
For more information on Google Analytics cookies, see the official Google Analytics page.
From time to time we test new features and make subtle changes to the way that the site is delivered. When we are still testing new features these cookies may be used to ensure that you receive a consistent experience whilst on the site whilst ensuring we understand which optimisations our users appreciate the most.
Hopefully that has clarified things for you and as was previously mentioned if there is something that you aren't sure whether you need or not it's usually safer to leave cookies enabled in case it does interact with one of the features you use on our site. This Cookies Policy was created with the help of the Cookies Policy Template Generator and the Privacy Policy Template Generator.
However if you are still looking for more information then you can contact us through one of our preferred contact methods:
Email: email@email.com


| CS 111 - Introduction to Computer Science
Homework #7 |
1. Average Pig Turns: In file
AveragePigTurns.java, implement this
specification. In addition, while Scanner
input/output will take place only in the main method, all solitaire game
simulation and average turn computation should take place in a method
getAverageTurns that takes an integer parameter for the number of games to
simulate, and returns a double-precision floating-point average turn computation.
The main method will read the desired number of simulations, call
method
getAverageTurns with that number, and report the returned number in the
specified format. Note: You'll
want to copy your PigSolitaireGame.java
code as a starting point.
2. Two-Computer-Player Pig: In file PigComputerGame.java,
implement this
specification. Note: You'll want to copy your PigSolitaireGame.java
code as a starting point.
3. Pig First Player Advantage: In file PigAdvantage.java,
implement this
specification. In addition, while Scanner
input/output will take place only in the main method, all solitaire game
simulation and computation of the first player win probability estimate should take place in a method
getAdvantage that takes an integer parameter for the number of games to
simulate, and returns a double-precision floating-point first player win
probability. The main method will read the desired number of
simulations, call method
getAdvantage with that number, and report the returned number in the
specified format. Note: You'll want to copy your PigComputerGame.java
code as a starting point.


File
Download Resume as PDF
Contact
Projects
IBM Watson Connect 4
Invisible Thread Website
MultiPlayer Tetris
View
Github
LinkedIn
Type Commands
Education
Work
Languages
Github
LinkedIn
Projects
About


Frequently Asked Questions
- Are you accessible outside the corporate areas?
- Do you accept cash only?
- NO, we accept Visa, MasterCard, Paypal and BitCoin.
- Can I get take the driver's number for use outside of this platform?
- Fan Down Taxi takes no responsibility for transactions outside of this platform.
- Can I use Fan Down Taxi as a courier?
- NO, we will not accept that liability.
- Can I use Fan Down Taxi for excursions and trips?
- Yes, as long as our policies are not breached.


You have been accepted as part of our [[profession]] cohort to attend the conference! Please complete the following form to confirm your attendance.


| CONTENTS |
When you first log in to a Unix system, the login program performs various security measures. These vary slightly from Unix variant to Unix variant, but they are largely the same.
First, login checks to see if you are not the root user and whether the file /etc/nologin exists (it is created by the shutdown command to indicate that the system is being brought down for maintenance). If both of these conditions are true, the login program prints the contents of that file to the terminal, and the login fails. If you are the root user, however, you will be allowed to log in.
Second, login checks to see if there are any special conditions on your login attempt (which may be defined in /etc/usertty or /etc/securetty), such as on which tty you're coming in. Linux systems do this, for example. Some systems (such as Darwin and other BSD-based systems) also check /etc/fbtab and may restrict your access to any devices listed in that file. These systems may also log failed login attempts to a file, such as /var/log/failedlogin, if it exists.
login may also record the time of login in the file /var/log/lastlog, make an entry in the file /var/run/utmp, showing that you are successfully logged in (it is removed once you log out), and append the utmp entry to the file /var/log/wtmp , showing that you logged in. This wtmp record will be updated on logout, showing the duration of your login session.
If the file .hushlogin exists in the user's home directory, the login will be quiet; otherwise, the following sequence of events will occur. If the system has any special copyright information to display, it will be printed to the terminal, followed by the message of the day (usually stored in /etc/motd ), and the user's last login time and system of origin (from the wtmp file, as discussed in the previous paragraph). If you want your login to be quiet, simply touch ~/.hushlogin. If you want it to be noisy, remove the file.
Finally, if all other checks have passed and restrictions have been performed, login starts a shell for you. Which shell depends on what is set in your user database entry (/etc/passwd, NIS, or possibly NetInfo under Darwin). If the shell specified for you is not interactive (Section 3.4), you may well be denied a command line. This is common for POP and ftp-only user accounts, where /bin/true and /bin/false are often specified as shells to disallow shell logins from those accounts.
JP and SJC
Throughout the book, we will refer to terminals, terminal emulators, and other software that allows you, the end user, to interact with the computer via some character-driven screen. In the old days, most terminals were separate hardware, but nowadays they're usually software. Mac OS X is no exception: its Terminal application, found in the Utilities folder of your Applications folder, is a terminal emulator.
You can launch Terminal by double-clicking on the icon in the Finder, or if you have the Terminal icon in your Dock, by single-clicking on that icon.
Once launched, Terminal may be configured as most Mac applications can: by setting preferences in the Preferences dialog and choosing a font family and size from the Font menu.
One big difference between Terminal and other, X-specific applications is that instead of running individual instances of xterm, you run one instance of Terminal and may have multiple windows, known as "shells," which may have saved settings (such as color, size, font choice, and various other settings). You can't run a shell in Mac OS X without running Terminal.
SJC
To understand setup files, you need to understand that a shell can act like a login shell or a nonlogin shell (Section 3.4). There are different setup files for nonlogin and login shells.
When you log in to a Unix system but not under a window system the login program starts a shell for you. The login program sets a special flag (Section 3.19) to tell a shell that it's a login shell. If the shell doesn't have that flag set, it won't act like a login shell. Opening a new window in a window system may or may not set the "login shell" flag that depends on the configuration. (For example, the command xterm -ls starts a login shell in an xterm window (Section 24.20); xterm +ls starts a nonlogin shell.) When you connect to a system with programs like ftp and scp, that usually starts a nonlogin shell. And a subshell (Section 24.4) is never a login shell (unless you set a command-line option to force a login shell, like bash -l).
How can you tell whether your shell is a login shell? The answer is "it depends." When you first log in to a system, you want a login shell that sets things like the terminal type (Section 5.2, Section 5.3). Other shells on the same terminal should be nonlogin shells to avoid redoing those one-time-only setup commands. Different shells have their own methods for handling first-time shell invocations versus later invocations, and that's what the rest of this article is about.
Parenthesis operators (Section 43.7) don't read any setup file. Instead, they start another instance of your current shell. Parentheses are called "subshell operators," but the subshell they start doesn't print a prompt and usually has a short lifetime.
Next, let's look at the setup files login and nonlogin for the major shells. I recommend that you read about all of them. Then experiment with your shell's setup files until you get things working the way you want them.
Your login(1) command probably sets some environment variables ( Section 35.3) like HOME, PATH, SHELL, TERM, MAIL, and LOGNAME or USER; check its manual page. Your system may set some environment variables or other parameters that apply to all shells or to all shells of a particular type (all bash shells, zsh shells, etc.). All of these will be passed through the environment, from parent process to child process (Section 35.4), to all of your shells, login and nonlogin.
Once login or your window system starts your individual shell, it may also read its own system-wide setup files. These files, if any, will be read before your personal setup files. Check your shell's manual page and the /etc directory for files like csh.login, bashrc, zshrc, and so on. On Red Hat systems, for example, there is a directory named /etc/profile.d containing package-specific C and Bash shell config files that are sourced (read into the current shell) on startup of a shell. On Mac OS X, when you use Terminal (Section 3.2), your shell (which is tcsh by default) reads /private/etc/csh.cshrc, as well as any user-specific files (e.g., ~/.tcshrc).
The original Bourne shell has one file that it reads when you log in: it's called .profile and is in your home directory. Put all your setup commands there. Later versions of the Bourne shell may also read /etc/profile before your local setup file is read and may also read the contents of whatever file is named in the ENV environment variable (Section 35.3) (but only for interactive shells). You may set this variable from your own .profile:
ENV=$HOME/.mystartup; export ENV
The Bourne shell doesn't read .profile when you start a nonlogin shell or subshell (Section 43.7), though. Subshells are set up through inheritance of environment variables (Section 35.3) that were set when you first logged in (in system-wide setup files or .profile) or from commands you typed since.
C shell users have several shell setup files available:
The .cshrc file is read any time a C shell starts that includes shell escapes and shell scripts.[1] This is the place to put commands that should run every time you start a shell. For instance, shell variables like cdpath (Section 31.5) and prompt should be set here. Aliases (Section 29.2) should, too. Those things aren't passed to subshells through the environment, so they belong in .cshrc (or .tcshrc). See the upcoming section on tcsh for more details.
Alternately, you can put aliases into a separate file and use the source command to read the file into the current shell from your .cshrc/.tcshrc if you're the sort who likes to have custom init files for every host you log in to, but like your aliases to be common wherever you go. This provides a quick and easy way for you to copy your .csh.aliases (or whatever name you give it, being careful to distinguish between it and the slightly different format required by bash aliases) from host to host without clobbering your custom, localized init files.
When csh starts up, on recent systems it may read a system-wide setup file, such as /etc/csh.cshrc,[2] and for login shells, /etc/csh.login.
Your .login file is read when you start a login shell. You should set several things here. Set environment variables (Section 35.3) (which Unix will pass to subshells automatically). Run commands like tset (Section 5.3) and stty (Section 5.7, Section 5.8) that set up your terminal. Finally, include commands you want to run every time you log in checking for mail and news (Section 1.21), running fortune, checking your calendar for the day, etc.
Note that .cshrc is read before .login, by csh, but that tcsh may be compiled such that the order is reversed, and .tcshrc may be read after .login in some environments. Check the version shell variable to find out how your environment is set up.
The shell reads .logout when you end a login shell. Section 3.8 has tips for reading .logout from nonlogin shells.
The Korn shell is a lot like the Bourne shell. A login Korn shell (Section 3.4) will read the .profile first; recent versions do so only after reading /etc/profile, if present. The .profile can set the ENV (Section 35.5) environment variable to the pathname of a file (typically $HOME/.kshrc). Any child Korn shell started by that login shell including all subshells will read the file named by $ENV as it starts up, before printing a prompt or running other commands.
The public domain Korn shell often found on Linux may also be further restricted when invoked as a "privileged" shell, using a pattern that matches r*sh, in which case neither the ~/.profile nor the file named by the ENV environment variable will be read. Instead, the shell will be initialized using /etc/suid_profile, if present.
bash is something of a cross between the Bourne and C shells. A login bash will read .bash_profile , .bash_login, or .profile. A noninteractive bash will read a file named .bashrc in your home directory. The shell reads .bash_logout when you end a login shell; you can set a trap (Section 4.18) to handle nonlogin shells.
bash also uses GNU Readline for reading and editing text you enter at a shell prompt. The .inputrc file configures Readline for a given user; /etc/inputrc is for global configuration.
tcsh is like the C shell but more flexible. If a tcsh shell is run, it first tries to read .tcshrc and, if not found, then tries .cshrc. In addition, tcsh will also load either .history or the value of the histfile variable, if set; then it may try to read .cshdirs or the value of the dirsfile variable.
As always, zsh is very flexible. Startup files are read from the directory named in the ZDOTDIR environment variable, if any;[3] otherwise, from HOME. All shells read the global /etc/zshenv and your .zshenv files. If the shell is a login shell, commands are read from /etc/zprofile and then your .zprofile. Then, if the shell is interactive, commands are read from /etc/zshrc and your .zshrc. Finally, if the shell is a login shell, /etc/zlogin and your .zlogin files are read.
JP and SJC
Each Unix shell (sh, csh, etc.) can be in interactive mode or noninteractive mode. A shell also can act as a login shell or a nonlogin shell. A shell is a shell is a shell e.g., a login bash shell is the same program (like /bin/bash) as a nonlogin bash shell. The difference is in the way that the shell acts: which setup files it reads, whether it sets a shell prompt, and so on.
When you first log in to a Unix system from a terminal, the system normally starts a login shell. (Section 3.4) A login shell is typcally the top-level shell in the "tree" of processes that starts with the init (Section 24.2) process. Many characteristics of processes are passed from parent to child process down this "tree" especially environment variables (Section 35.3), such as the search path (Section 35.6). The changes you make in a login shell will affect all the other processes that the top-level shell starts including any subshells (Section 24.4).
So, a login shell is where you do general setup that's done only the first time you log in initialize your terminal, set environment variables, and so on. A shell "knows" (Section 3.19) when it's a login shell and, if it is, the shell reads special setup files (Section 3.3) for login shells. For instance, login C shells read your .login file, and Bourne-type login shells read .profile. Bash may also read /etc/profile, and ~/.bash_profile or ~/.bash_login or ~/.profile, depending on whether those files exist and whether the -noprofile option has been passed (which would disable reading of any startup files).
Nonlogin shells are either subshells (started from the login shell), shells started by your window system (Section 24.20), or "disconnected" shells started by at (Section 25.5), rsh (Section 1.21), etc. These shells don't read .login or .profile. In addition, bash allows a nonlogin shell to read ~/.bashrc or not, depending on whether the -norc or -rcfile options have been passed as arguments during invocation. The former simply disables reading of the file, and the latter allows a substitute file to be specified as an argument.
Some shells make it easy to know if a particular invocation is a login shell. For instance, tcsh sets the variable loginsh. Check your shell's manual page for details. Section 4.12 shows another solution: the SHLVL variable that's set in most modern shells. Or you can add the following line to the beginning of a setup file that's only read by login shells (Section 3.3). The line sets a shell variable (Section 35.9) named loginshell:
set loginsh=yes ...csh loginshell=yes ...bash and other sh-type shells
Now wherever you need to know the type of shell, use tests like:
if ($?loginsh) ...csh-type shells if [ -n "$loginshell" ] ...sh-type shells (including bash)
This works because the flag variable will only be defined if a shell has read a setup file for login shells. Note that none of the variable declarations use the "export" keyword this is so that the variable is not passed on to subsequent shells, thereby ruining its purpose as a flag specific to login shells.
In general, shells are used for two jobs. Sometimes, a shell handles commands that you type at a prompt. These are interactive shells. Other times, a shell reads commands from a file a shell script (Section 35.2). In this case, the shell doesn't need to print a prompt, to handle command-line editing, and so on. These shells can be noninteractive shells. (There's no rule that only noninteractive shells can read shell scripts or that only interactive shells can read commands from a terminal. But this is generally true.)
One other difference between interactive and noninteractive shells is that interactive shells tie STDOUT and STDERR to the current terminal, unless otherwise specified.
It's usually easy to see whether a particular invocation of your shell is interactive. In C shells, the prompt variable will be set. In the Korn shell and bash, the -i flag is set. Your current flags may be displayed using the $- variable:
prompt$ echo $- imH
The previous example, from an interactive bash shell, shows that the flags for an interactive shell (i), monitor mode (m), and history substitution (H) have been set.
JP and SJC
Setup files for login shells ( Section 3.4) such as .login and .profile typically do at least the following:
Set the search path (Section 27.6) if the system default path isn't what you want.
Set the terminal type (Section 5.3) and make various terminal settings (Section 5.7, Section 5.8) if the system might not know your terminal (if you log in from various terminals over a dialup line or from a terminal emulator on a desktop machine, for instance).
Set environment variables (Section 35.3) that might be needed by programs or scripts that you typically run.
Run one or more commands that you want to run whenever you log in. For example, if your system login program doesn't show the message of the day, your setup file can. Many people also like to print an amusing or instructive fortune. You also might want to run who (Section 2.8) or uptime (Section 26.4) or w (a combination of the other two, but not found on all systems) for information about the system.
In the C shell, the .cshrc file is used to establish settings that will apply to every instance of the C shell, not just login shells. For example, you typically want aliases (Section 28.2) available in every interactive shell you run but these aren't passed through the environment, so a setup file has to do the job. You may wish to put all of your aliases into another file, such as .aliases, or qualify the name with the shell's name, such as .csh.aliases, to allow for different alias formats between shells, and then you can use the source command to read in that file on startup from .cshrc.
Even novices can write simple setup files. The trick is to make these setup scripts really work for you. Here are some of the things you might want to try:
Creating a custom prompt.
Coordinating custom setup files on different machines (Section 3.18).
Making different terminal settings depending on which terminal you're using (Section 3.10 and others).
Seeing the message of the day only when it changes.
Doing all of the above without making your login take forever.
TOR and SJC
The shell is your interface to Unix. If you make a bad mistake when you change your setup file (Section 3.3) or your password, it can be tough to log in and fix things.
Before you change your setup, it's a good idea to start a login session to the same account from somewhere else. Use that session for making your changes. Log in again elsewhere to test your changes.
Don't have a terminal with multiple windows or another terminal close to your desk? You can get the same result by using rlogin or telnet (Section 1.21) to log in to your host again from the same terminal. What I mean is:
somehost% vi .cshrc ...Make edits to the file... somehost% rlogin localhost ...Logs you in to your same account... An error message somehost% logout Connection closed. somehost% vi .cshrc ...Edit to fix mistake...
If you don't have rlogin or telnet, the command su - username, where username is your username, will do almost the same thing. Or, if you're testing your login shell configuration, login will do as well.
JP and SJC
One common mistake in shell setup files (Section 3.3) is lines like these:
$$ Section 27.17, `...` Section 28.14
source .aliases echo "Shell PID $$ started at `date`" >> login.log
What's wrong with those lines? Both use relative pathnames (Section 1.16) for the files (.aliases, login.log), assuming the files are in the home directory. Those lines won't work when you start a subshell (Section 24.4) from somewhere besides your home directory because your setup files for nonlogin shells (like .cshrc) are read whenever a shell starts. If you ever use the source or . commands (Section 35.29) to read the setup files from outside your home directory, you'll have the same problem.
Use absolute pathnames instead. As Section 31.11 explains, the pathname of your home directory is in the tilde (~) operator or the $HOME or $LOGDIR environment variable:
source ~/.aliases echo "Shell PID $$ started at `date`" >> ~/login.log
JP
The C shell reads its .cshrc, .login, and .logout setup files at particular times (Section 3.3). Only "login" C shells (Section 3.4) will read the .login and .logout files. Back when csh was designed, this restriction worked fine. The shell that started as you logged in was flagged as a login shell, and it read all three files. You started other shells (shell escapes, shell scripts, etc.) from that login shell, and they would read only .cshrc. The same can be said of other shell variants, such as tcsh, though they may have multiple startup files the problem of distinguishing between login and nonlogin shell startup is the same.
Now, Unix has interactive shells started by window systems (like xterm (Section 24.20)), remote shells (like rsh (Section 1.21) or ssh), and other shells that might need some things set from the .login or .logout files. Depending on how these shells are invoked, these might not be login shells so they might read only .cshrc (or .tcshrc, etc.). How can you handle that? Putting all your setup commands in .cshrc isn't a good idea because all subshells (Section 24.4) read it . . . you definitely don't want to run terminal-setting commands like tset (Section 5.3) during shell escapes!
Most other shells have the same problem. Some, like zsh and bash, have several setup files that are read at different times and probably can be set up to do what you want. For other shells, though, you'll probably need to do some tweaking.
To handle problems at login time, put almost all of your setup commands in a file that's read by all instances of your shell, login or nonlogin. (In the C shell, use .cshrc instead of .login.) After the "login-only" commands have been read from the setup file, set the ENV_SET environment variable (Section 35.3) as a flag. (There's nothing special about this name. You can pick any name you want.) You can then use this variable to test whether the login-only commands have already been run and skip running them again in nonlogin shells.
Because the environment variables from a parent process are passed to any child processes it starts, the shell will copy the "flag" variable to subshells, and the .cshrc can test for it. If the variable exists, the login-only commands are skipped. That'll keep the commands from being read again in a child shell.
Here are parts of a .cshrc that show the idea:
...Normal .cshrc stuff... if ($?prompt && ! $?ENV_SET) then # Do commands that used to go in .login file: setenv EDITOR /usr/ucb/vi tset ... setenv ENV_SET done endif
You might put a comment in the file you've bypassed the csh .login file, the ksh .profile file, etc. to explain what you've done.
The file that runs when you log out (in the C shell, that's .logout) should probably be read only once when your last ("top-level") shell exits. If your top-level shell isn't a login shell, you can make it read the logout file anyway. Here's how: first, along with the previous fixes to your .cshrc-type file, add an alias that will read your logout file when you use the exit command. Also set your shell to force you to use the exit command (Section 35.12) to log out in csh, for example, use set ignoreeof. Here's what the chunk of your .bashrc will look like:
case Section 35.10, / Section 36.25, function Section 29.11, . Section 35.29
case "$-/${ENV_SET:-no}" in *i*/no) # This is an interactive shell / $ENV_SET was not set earlier. # Make all top-level interactive shells read .bash_logout file: set -o ignoreeof function exit { . ~/.bash_logout builtin exit } ;; esac
The builtin exit (Section 27.9) prevents a loop; it makes sure bash uses its internal exit command instead of the exit function you've just defined. In the C shell, use ""exit (Section 27.10) instead. This isn't needed on all shells though. If you can't tell from your manual page, test with another shell (Section 3.6) and be ready to kill (Section 24.12) a looping shell.
JP and SJC
Lots of users add an if (! $?prompt) exit test to their .cshrc files. It's gotten so common that some vendors add a workaround to defeat the test. For instance, some versions of the which command (Section 2.6) set the prompt variable so that it can see your aliases "hidden" inside the $?prompt test. I've also seen a version of at that starts an interactive shell to run jobs.
If you've buried commands after if (! $?prompt) that should only be run on interactive shells or at login time, then you may have trouble.
There are workarounds. What you'll need depends on the problem you're trying to work around.
The version of which on the CD-ROM [see http://examples.oreilly.com/upt3] works without reading your .cshrc file, so there's no problem there.
Here's a way to stop the standard which from reading parts of your .cshrc that you don't want it to read. The first time you log in, this scheme sets a CSHRC_READ environment variable (Section 35.3). The variable will be copied into all subshells (Section 24.4) (like the one that which starts). In subshells, the test if ($?CSHRC_READ) will branch to the end of your .cshrc file:
if (! $?prompt) goto cshrc_end # COMMANDS BELOW HERE ARE READ ONLY BY INTERACTIVE SHELLS: alias foo bar ... if ($?CSHRC_READ) goto cshrc_end # COMMANDS BELOW HERE ARE READ ONLY AT LOGIN TIME: setenv CSHRC_READ yes ... cshrc_end:
If you have a buggy version of at (Section 25.5) that runs jobs from interactive shells, make your own frontend to at (Section 29.1) that sets an environment variable named AT temporarily before it submits the at job. Add a test to your .cshrc that quits if AT is set:
( ) Section 43.7, \at Section 29.8
# at JOBS RUN INTERACTIVE SHELLS ON MY BUGGY VERSION OF UNIX. # WORKAROUND IS HERE AND IN THE at ALIAS BELOW: if ($?AT) goto cshrc_end ... alias at '(setenv AT yes; \at \!*)' ... cshrc_end:
Most modern versions of at save a copy of your environment when you submit the job and use it when the at job is run. At that time, the AT environment variable will be set; the C shell will skip the parts of your .cshrc that you want it to. It's ugly, but it works.
Those workarounds probably won't solve all the problems on your version of Unix, but I hope they'll give you some ideas.
JP and SJC
If you work at several kinds of terminals or terminal emulators, terminal setup can be tough. For instance, my X terminal sends a backspace character when I push the upper-right key, but the same key on another terminal sends a delete character I want stty erase (Section 5.8) to set the correct erase character automatically.[4] Maybe you want a full set of calendar programs started when you log in to the terminal at your desk, but not when you make a quick login from somewhere else.
The next seven articles have ideas for changing your login sequence automatically. Some examples are for the C shell and use that shell's switch and if. Examples for Bourne-type shells use case (Section 35.10) and if (Section 35.13). If you use the other type of shell, the idea still applies; just swap the syntax.
If you use several kinds of terminals or terminal emulators, try testing the TERM environment variable (Section 3.11). Testing other environment variables (Section 3.14) can identify the frontend system (like a window system) you're using.
Test the output of who am i (Section 3.12) to find out about the remote system from which you've logged in.
If you log into different kinds of ports network, hardwired, and so on search for the port type (Section 3.15) in a table like /etc/ttys (in BSD derivatives) or /etc/inittab (in some other variants). Testing the port name (Section 3.13) may also work.
In the X Window System, you can test the window size (Section 3.16) and make various settings based on that. Naming windows (Section 3.17) lets you identify a particular window by reading its environment.
You can also handle some of these cases using the venerable but obscure tset (Section 5.3) program to select and initialize the correct terminal type. Another program that sets the terminal type is qterm (Section 5.4).
Because your terminal type doesn't change after you've logged in, many of these tests probably belong in your .profile or .login file. Those setup files are read when you first log in to a tty. Other tests, especially ones that involve windows, will probably fit better in a per-shell setup file such as .bashrc or .cshrc. Section 3.3 can help you choose.
JP and SJC
If you use several different kinds of terminals (or, as is far more common these days, terminal emulators) and your TERM environment variable is set differently on each terminal, you can add a test like this to your C shell .login file:
switch ($TERM) case vt100: ...do commands for vt100 breaksw case xxx: ...do commands for xxx breaksw default: ...do commands for other terminals breaksw endsw
If you have a Bourne-type shell, use a case statement (Section 35.10) in your .profile instead:
case "$TERM" in vt100) ...do commands for vt100 ;; xterm) ...do commands for xterm ;; *) ...do commands for other terminals ;; esac
JP and SJC
If you log in from other hosts (Section 1.21) or from hosts running the X Window System (Section 24.20), the who am i[5] command will probably show a hostname and/or window information in parentheses:
schampeo@fugazi:1002 $ who am i schampeo ttyp7 Jun 19 03:28 (fugazi:0.0)
(Long hostnames may be truncated. Also, note that some versions of who am i prepend the name of the local host to the username and don't include the remote hostname at all in their output. Check yours before you write this test.) The information in parentheses can help you configure your terminal based on where you've logged in from and/or which display you're using. To test it, add commands such as the following to your .profile file. (In C-type shells, use a switch statement in .login instead.)
case Section 35.10
case "`who am i | sed -n 's/.*(\(.*\))/\1/p'`" in
\(..\) \1 Section 34.11
*0.0) ...do commands for X display 0 ;; mac2*) ...do commands for the host mac2.foo.com ;; "") ...no output (probably not a remote login) ;; *) ...do commands for other situations ;; esac
That uses sed (Section 34.1) to give the text between the parentheses for that remote host to the case. This *0.0 case matches lines ending with 0.0; the mac2 case matches lines that start with mac2; an empty string means sed probably didn't find any parentheses; and the * case catches everything else.
JP and SJC
If you know that certain port (tty) numbers are used for certain kinds of logins, you can test that and change your terminal setup based on the tty you're currently using. For example, some systems use ttyp0, ttyq1, etc. as network ports for rlogin and ssh (Section 1.21), while others use pty0, etc. This Bourne-type case statement branches on the port name:
tty Section 2.7
case "`tty`" in /dev/tty[pqrs]?) # rlogin, telnet: ... /dev/tty02) # terminal on my desk: ... "not a tty") ;; ...not a terminal login session; do nothing esac
In C-type shells, try a switch or if statement instead.
On Linux, you may need to look for patterns to match /dev/pts/0, /dev/pts/1, etc.
JP and SJC
Certain systems set certain environment variables. For example, the X Window System sets a DISPLAY environment variable (Section 35.5). If you've logged in from a remote system using ssh (Section 1.21), look for variables like SSH_CLIENT and SSH_TTY or SSH_AUTH_SOCK on the system you log in to. (If you aren't sure about your system, use the env or printenv command (Section 35.3) to look for changes in your environment at different systems.)
Your shell setup file (Section 3.3) makes decisions based on the environment variables that have been set. Here are examples for both C-type and Bourne-type shells:
[ ] Section 35.26
if ($?DISPLAY) then if [ -n "$DISPLAY" ]; then # on X window system # on X window system ... ... else if ($?XDARWIN_VERSION) then elif [ -n "$XDARWIN_VERSION" ]; then # on MacOS X system # on MacOS X system ... ... else else ... ... endif fi
JP and SJC
Your system may have an /etc/ttytab or /etc/ttys file that lists the type of each terminal port (tty (Section 24.6)).[6]
For example, port ttyp0 is network, the type used by xterm (Section 24.20), telnet (Section 1.21), etc.
To change your account configuration based on the tty port type, match the first column of that file to the output of the tty (Section 2.7) command, which shows your current tty pathname. The output of tty starts with /dev or /dev/pts. So, to match your current tty to the file, you need to strip the name to its tail. For example, in bash and ksh, these three lines would put the terminal port type (vt100, plugboard, etc.) into the ttykind shell variable:
tty=`tty` ttytail=${tty#/dev/}
awk Section 20.10
ttykind=`awk '$1 == "'$ttytail'" {print $3}' /etc/ttys`
Then you can test the value with case (Section 35.10) or if (Section 35.13). In C shells, you can set ttytail by using the :t string modifier (Section 28.5) and test its value with switch or if.
JP and SJC
I use several terminal windows of different sizes. I don't stretch the windows after I open them; instead, I set the size as I start each xterm. Here's an excerpt from my X setup file (Section 3.20) that opens the windows:
-e Section 5.22
xterm -title SETI -geometry 80x9+768+1 -e setiathome -verbose -nice 10 & xterm -title "work xterm" -geometry 80x74+329-81 &
The first window has 9 rows (80x9) and the second has 74 rows (80x74).[7] I'd like the less (Section 12.3) pager to use different jump-target lines in larger windows. If the window has more than 24 lines, I want less to use its option -j3 to show search-matches on the third line of the window instead of the first.
On many systems, the command stty size gives the number of rows and columns in the current window, like this:
$ stty size 74 80
Your system might need the command stty -a instead or it could have environment variables named LINES and COLUMNS. We'll use stty size in the following Bourne shell setup file. The set (Section 35.25) command puts the number of rows into the $2 shell parameter. (Using set this way is portable to all shells, but it's a clumsy way to split stty's output into words. If you have a newer shell with array support, it'll be easier.) Then a series of if (Section 35.13)/then (Section 35.26) tests handle different window sizes:
LESS=emqc; export LESS # Put number of rows into $2, configure session based on that: set x `stty size` if [ -z "$2" -o "$2" -lt 1 ] then echo ".profile: bogus number of rows ($2) in window!?" 1>&2 elif [ "$2" -gt 24 ] then LESS=j3$LESS ... fi
Additionally, you may be able to run resize on machines with the X Window System installed; it may output something like this:
schampeo@fugazi:1046 $ resize COLUMNS=80; LINES=37; export COLUMNS LINES;
You may then capture the output and read it for the current setting or simply check the COLUMNS or LINES environment variables.
JP and SJC
I use several xterm windows. Here's an excerpt from my X setup file (Section 3.20):
WINNAME=console xterm -C -title Console -geometry 80x9+0+0 & WINNAME=work xterm -title "work xterm" -geometry 80x74+329-81 &
The WINNAME=name sets an environment variable named WINNAME for the particular command line it's on. This is passed through the environment, through the xterm process, to the shell running inside the window. So the shell's setup file can test for this variable and, by knowing the window name stored in that variable, do specific setup for just that window. For example, in tcsh:
-fSection 11.10, { }Section 28.4
if ($?WINNAME) then switch ($WINNAME) case console: # Watch logs: tail -f /var/log/{messages,maillog,secure} ~/tmp/startx.log & breaksw case work: /usr/games/fortune fetchmail breaksw endsw endif
On the console terminal, this .tcshrc file starts a job in the background (Section 23.2) to watch log files. On the work xterm, I get a fortune and grab email from the POP server.
JP and SJC
I work with different types of machines every day. It is often necessary to set things up differently for, say, a Linux box than a SPARCstation or a MacOS X box. Going beyond that, you may want to set things up differently on a per-host basis.
I have this test in my .cshrc file:
setenv Section 35.3
setenv HOST "`uname -n`"
if (-e ~/lib/cshrc.hosts/cshrc.$HOST) then source ~/lib/cshrc.hosts/cshrc.$HOST endif
So, if I log in to a machine named (Section 2.5) bosco, and I have a file called ~/lib/cshrc.hosts/cshrc.bosco, I can source (Section 35.29) it to customize my environment for that one machine. These are examples of things you would put in a .cshrc.$HOST file:
Some machines have /usr/local/bin, and some have /opt. The same goes for cdpath (Section 31.5).
I always like to reach for the upper-right part of a keyboard to erase characters. Sometimes this is the location for the BACKSPACE key, and sometimes it is the DELETE key. I set things up so that I can consistently get "erase" behavior from whatever key is there.
These may be different. You may run a package on a certain machine that relies on a few environment variables. No need to always set them and use up a little bit of memory if you only use them in one place!
In general, this idea allows you to group together whatever exceptions you want for a machine, rather than having to write a series of switch or if statements throughout your .cshrc and .login files. The principle carries over directly to the newer shells as well.
DS and SJC
When you log in to most Unix systems, your shell is a login shell. When a shell is a login shell, it acts differently (Section 3.4).
Sometimes, when you're testing an account or using a window system, you want to start a login shell without logging in. Unix shells act like login shells when they are executed with a name that starts with a dash (-).[8] This is easy to do if you're using a system call in the exec(3) family. These system calls let a C-language programmer give both the filename of an executable file, like sh or /bin/sh, as well as the name that should be used to identify the process (in a ps (Section 24.5) listing, for example), like -sh.
If you're currently using zsh, you can invoke another shell this way by typing a dash and a space before the shell's name:
zsh% - csh ...C shell starts, acting like a login shell... %
C programmers can write a little program that runs the actual shell but tells the shell that its name starts with a dash. This is how the Unix login process does it:
run_login_csh( ) { execl("/bin/csh", "-csh", 0); }
A more general solution is to make a link (Section 10.4) to the shell and give the link a filename starting with a dash. If your own bin subdirectory is on the same filesystem as /bin (or wherever the executable shell file is), you can use a hard link. Otherwise, make a symbolic link, as shown here:
bin Section 7.4, ./- Section 14.13
$ cd $HOME/bin $ ln -s /bin/csh ./-csh
Then you can execute your new shell by typing its name:
$ -csh ...normal C shell login process... % ...run whatever commands you want... % logout $ ...back to original shell
JP and SJC
One way to set defaults for your applications is with environment variables (Section 35.3) that the applications might read. This can get messy, though, if your environment has tens or hundreds of variables in it. A lot of applications have a different way to choose defaults: setup files, similar to shell setup files (Section 3.3). Most of these filenames end with rc, so they're often called RC files.[9] Today's more-complex applications also use their own setup subdirectories. Almost all of these files and directories are hidden (Section 8.9) in your home directory; you'll need ls -A to see them.
This article describes some of the most common setup files. For a more complete list, check your application's manpage:
For the Emacs editor. See Section 19.3.
For the vi (actually, ex) editor. See Section 17.5.
For the GNU Readline library and applications that use it, such as the bash shell.
For the mail (Section 1.21) program and others like it. This can be handy if you use mail from the command line to send quick messages. For example:
# If I send mail to "bookquestions", send it to myself too: alias bookquestions<EMAIL_ADDRESS>jerry # When I send a message, prompt me for "cc:" addresses: set askcc
For the MH email system.
A listing of hostnames, accounts and possibly passwords used for connecting to remote hosts with ftp and some other programs. Should have file access mode (Section 50.2) 600 or 400 for security, but this may not be enough protection for passwords! Best used for Anonymous ftp.
For news readers (Section 1.21). (Some newer news readers have more complex files.) A list of newsgroups in the order you want to see them. For example:
comp.security.announce: 1-118 news.announce.important: 1 comp.org.usenix: 1-1745 comp.sys.palmtops! 1-55069,55071 ...
 After each name is a list of the article numbers you've read in that newsgroup; a range like 1-55069 means you've read all articles between number 1 and number 55069.
A list of remote hostnames that are allowed to access your local machine with clients like rsh and rlogin (Section 1.21). Remote usernames are assumed the same as your local username unless the remote username is listed after the hostname. This file can be a security hole; make its file access mode (Section 50.2) 600 or 400. We suggest you only use it if your system or network administrator approves. For example:
rodan Allow a user with same username from host rodan foo.bar.com joe Allow username joe from host foo.bar.com
For xauth, a program that handles authorization information used in connecting to the X Window System server.
A resource file (Section 6.5) for the X Window System. Sometimes also called .xrdb.
A shell script (Section 35.2) that runs as you log in to an X Window System session using xinit. (Also see .xsession, later in this list.)
All commands except the last typically end with an ampersand (&), which makes those clients run in the background. The last command becomes the controlling process; when that process exits (for instance, you use the window manager's "quit" command), the window system shuts down. For example:
$Id Section 39.5, exec > Section 36.5, -v Section 35.25, uname -n Section 2.5 , ${..:=..} Section 36.7, export Section 35.3, xrdb Section 6.8, sh -c Section 24.21, exec Section 36.5
#! /bin/sh # $Id: ch03.xml,v 1.36 2002/10/13 03:50:01 troutman Exp troutman $ # Usage: .xinitrc [DISPLAY] wm=fvwm2 # window manager # Put all output into log that you can watch from a window (tail -f): mv -f $HOME/tmp/startx.log $HOME/tmp/,startx.log exec > $HOME/tmp/startx.log 2>&1 set -v # Set DISPLAY from $1 if the X server isn't on same host as client: if [ $# -gt 0 ] then if [ $# -ne 1 ] then echo "Usage: .xintirc [DISPLAY]" 1>&2 exit 1 else DISPLAY=$1 fi else host=`uname -n` DISPLAY=${DISPLAY:=$host:0.0} fi export DISPLAY xrdb -load $HOME/.xrdb # # Clients # xterm -C -geometry 80x9+0+0 -sl 2000 & oclock -geometry -1+1 & xterm -title "SETI console" -bg blue -fg white -geometry 80x9+768+1 -e \ sh -c 'cd /var/cache/seti && exec ./setiathome -nice 5 -verbose' & # Don't use -e because Mozilla crashes; start by hand from prompt: xterm -title "Mozilla console" -bg orange -geometry 80x9-0+1 & xterm -geometry 80x74+329-81 & # # Start window manager # exec $wm
An executable file (generally a shell script (Section 35.2), but it can be any executable) that runs as you log into an X Window System session using xdm. See .xinitrc, earlier in this list.
Last but not least, your system probably has a lot of setup files in its /etc directory. Look for subdirectory or filenames starting with rc. These are read when your system reboots or changes its runlevel (for example, from single-user mode to multiuser mode). These files are basically shell scripts (Section 35.2). If you know a little about shell programming, you can learn a lot about your system by looking around these files.
JP and SJC
We strongly suggest that you write a manual page for each command that you place in your bin directory. Unix manual pages typically have the following format, which we suggest you follow:
NAME The program's name; one line summary of what it does. SYNOPSIS How to invoke the program, including all arguments and command-line options. (Optional arguments are placed in square brackets.) DESCRIPTION A description of what the program doesas long as is necessary. OPTIONS An explanation of each option. EXAMPLES One or more examples of how to use the program. ENVIRONMENT Any environment variables that control the program's behavior. FILES Files the program internals will read or write. May include temporary files; doesn't include files on the command line. BUGS Any known bugs. The standard manual pages don't take bug recording seriously, but this can be very helpful. AUTHOR Who wrote the program.
To see how a "real" manual page looks, type man ls.
Feel free to add any other sections that you think are necessary. You can use the nroff -man macros (Section 3.22) if you want a nicely formatted manual page. However, nroff is fairly complicated and, for this purpose, not really necessary. Just create a text file that looks like the one we showed previously. If you are using a BSD system and want your manual pages formatted with nroff, look at any of the files in /usr/man/man1, and copy it.
|
The man (Section 2.1) command is essentially the same as this:
-s Section 11.7
% nroff -e -man filename | more -s
Go to http://examples.oreilly.com/upt3 for more information on: gnroffawf
You can safely omit the -e option to nroff and the -s option to more, or even substitute in your favorite pager, such as less. And remember that nroff may not be available on all systems, but the web site has gnroff and awf. In fact, on some systems, nroff is simply a script that emulates the real nroff using groff.
Now, you want to make this manual page "readable" by the standard man command. There are a few ways to do this, depending on your system. Create the directory man in your home directory; create the directory cat1 as a subdirectory of man; then copy your manual entry into cat1, with the name program.1 (where program is the name of your special command). When you want to read the manual page, try the command:
% man -M ~/man program
|
Some systems have a MANPATH environment variable (Section 35.3), a colon-separated list of directories where the man command should look. For example, my MANPATH contains:
/home/mike/man:/usr/local/man:/usr/man
MANPATH can be more convenient than the -M option.
|
If you are sharing your program with other people on the system, you should put your manual entry in a public place. Become superuser and copy your documentation into /usr/local/man/catl, giving it the name program.l (the "l" stands for "local"). You may need to create /usr/local and /usr/local/man first. If you can't become superuser, get the system administrator to do it for you. Make sure that everyone can read the manual page; the permissions should be something like this:
% ls -l /usr/local/man/catl -r--r--r-- 1 root 468 Aug 5 09:21 program.l
Then give the command man program to read your documentation.
If you are working on some other systems, the rules are a little different. The organization of the manual pages and the man command itself are slightly different and really, not as good. Write your manual entry, and place it in your doc directory. Then create the following C shell alias (Section 29.3):
less Section 12.3
alias myman "(cd ~/doc; man -d \!$ | less)"
or shell function (Section 29.11):
myman( ) { (cd $HOME/doc; man -d "$1" | less); }
Now the command myman docfilename will retrieve your manual page. Note that if you use a section-number extension like .1, you have to give the entire filename (e.g., program.1), not just the program's name.
If you want to make your manual page publicly available, copy the file into the system manual page directory for section 1; you may have to become superuser to do so. Make sure that anyone on the system can read your file. If the entry is extremely long and you want to save space in your filesystem, you can use the gzip (Section 15.6) utility on your documentation file. The resulting file will have the name program.1.gz; newer versions of the man command will automatically uncompress the file on-the-fly.
ML and SJC
If you're not satisfied with the simple manual pages we discussed in Section 3.21, here's how to go all the way and create a "real" manual page. As we said, the best way to create a manual page is to copy one that already exists. So here's a sample for you to copy. Rather than discuss it blow by blow, I'll include lots of comments (these start with .\" or \").
.\" Title: Program name, manual section, and date
.TH GRIND 1 .\" Section heading: NAME, followed by command name and one line summary .\" It's important to copy this exactly; the "whatis" database (used .\" for apropos) looks for the summary line. .SH NAME grind \- create output from input .\" Section heading: SYNOPSIS, followed by syntax summary .SH SYNOPSIS .B grind \" .B: bold font; use it for the command name. [ -b ] [ -c ] [ -d ] \" Put optional arguments in square brackets. [ input [ output ]] \" Arguments can be spread across several lines. .br \" End the synopsis with an explicit line break (.br) .\" A new section: DESCRIPTION, followed by what the command does .SH DESCRIPTION .I Grind \" .I: Italic font for the word "Grind" performs lots of computations. Input to .IR grind , \" .IR: One word italic, next word roman, no space between. is taken from the file .IR input , and output is sent to the file .IR output , which default to standard input and standard output if not specified. .\" Another section: now we're going to discuss the -b, -c, and -d options .SH OPTIONS .\" The .TP macro precedes each option .TP .B \-b \" print the -b option in bold. Print output in binary. .TP .B \-c \" \- requests a minus sign, which is preferable to a hyphen (-) Eliminate ASCII characters from input before processing. .TP .B \-d Cause daemons to overrun your computer. .\" OK, we're done with the description and the options; now mention .\" other requirements (like environment and files needed) as well as .\" what can go wrong. You can add any other sections you want. .SH FILES .PD 0 .TP 20 .B /dev/null data file .TP .B /tmp/grind* temporary file (typically 314.159 Gigabytes) .PD .SH BUGS In order to optimize computational speed, this program always produces the same result, independent of the input. .\" Use .LP between paragraphs .LP If the moon is full, .I grind may destroy your input file.  Good manual pages end by stating who wrote the program. .SH AUTHOR I wouldn't admit to this hack if my life depended on it.
After all that, you should have noticed that there are four important macros (listed in Table 3-1) to know about.
|
Macro |
Meaning |
|---|---|
|
.TH |
Title of the manual page. |
|
.SH |
Section heading; one for each section. |
|
.TP |
Formats options correctly (sets up the "hanging indent"). |
|
.LP |
Used between paragraphs in a section. |
For some arcane reason, all manual pages use the silly .B, .BI, etc. macros to make font changes. I've adhered to this style in the example, but it's much easier to use inline font changes: \fI for italic, \fB for bold, and \fR for roman. There may be some systems on which this doesn't work properly, but I've never seen any.
ML and SJC
[1] If you write a csh (or tcsh) script, you probably should use the -f option to keep scripts from reading .cshrc (or .tcshrc). However, you probably shouldn't use csh or tcsh for scripts.
[2] On Mac OS X, /etc is a symbolic link to /private/etc. The actual initialization files for tcsh are in /usr/share/init/tcsh.
[3] ZDOTDIR may be hard to set on your first login when your zsh is a login shell because it's hard to set an environment variable before your first shell starts. (The system program that starts your shell, like login(1), could do the job, I guess.)
[4] Of course, it is all arbitrary and contingent on your keyboard layout and configuration.
[5] Also try "who mom likes" or maybe "who is responsible?" the who doesn't really care, as long as there are only two arguments. So, "who let the dogs out?", as you might expect, causes an error.
[6] Then again, it may not. The RedHat Linux system I tested this on did not; the MacOS X 10.1.5 box I tested it on did.
[7] Both windows have 80 columns. This is a Unix custom that comes from "the old days" when terminals all were 80 columns wide. But it's still a common width today and a good default when you don't need a wider window. Some people are even sort of weird about it, especially for reading email.
[8] bash also has a command-line option, -login, that makes it act like a login shell. zsh -l (lowercase L) does the same for zsh.
[9] Don't ask me why. It's one of those acronyms, like spool (Section 45.2), that's open to interpretation, though one theory is that it is derived from "runcom files," (possibly short for "run commands") on the Compatible Time-Sharing System, c.1962-63 (source: The Jargon File).
| CONTENTS |


-
lineIntersection(p1, p2, p3, p4) → {Point}
-
Parameters:
| Name |
Type |
Description |
p1 |
Point
|
|
p2 |
Point
|
|
p3 |
Point
|
|
p4 |
Point
|
|
- Source:
Returns:
-
Type
-
Point
-
loadMap(size, margin, blocks, walls)
-
Load a set of square blocks, plus any other line segments
Parameters:
| Name |
Type |
Description |
size |
|
|
margin |
|
|
blocks |
Array
|
Array of Block |
walls |
Array
|
Array of Segment |
- Source:
-
setLightLocation(x, y)
-
Set the light location. Segment and EndPoint data can't be
processed until the light location is known.
Parameters:
| Name |
Type |
Description |
x |
Float
|
|
y |
Float
|
|
- Source:
-
sweep(maxAngle)
-
Run the algorithm, sweeping over all or part of the circle to find
the visible area, represented as a set of triangles
Parameters:
| Name |
Type |
Description |
maxAngle |
Float
|
|
- Source:


The town of Cesme is tucked in on the western side of the peninsula of Kalem Burnu, opposite the town of Khios (Chios) on the Greek island of the same name. It is an attractive small town and a popular tourist destination with good beaches.
Photo: Approaching Cesme (courtesy of MV LeeZe)
For the full details on Turkey Formalities go here.
The Customs and Immigration Authorities are in the ferry Terminal building and the Health Authority and Harbourmaster in the SE corner of the port.
The formalities can also be completed at Setur Cesme Marina by visiting officials.
June 2014 cruisers reported that the Blue Card Scheme (black and grey tank regulations) is currently not being enforced at this port.
The Camper & Nicholson marina (opened June 2010) in the centre of Cesme provides excellent facilities and the Setur Cesme marina, on the opposite side of the peninsula, provides fully serviced berths. In addition there has now been developed another marina at Port Alacati, about 15NM south of Cesme.
It is possible to anchor off the town, however it is difficult to find a spot protected from the N/NW wind. There are also a few forbidden zones in this harbour.
It may be possible to come stern-to the town quay (Med-moor using your own anchor), which gets busy with gulets and charter boats. Speak with the harbour master. There is no electricity here, but water can be delivered by tanker. The city are working on getting shore power and water to the quay. The town quay is better protected from Northerly winds but offers little protection from Southerly ones. If the wind blows hard from the South it is advisable to move to anchor in the middle of the bay or to a protected bay south of the harbour. (Photo of town quay courtesy of MV LeeZe, June 2014).
There are several good anchorages in the area.
Last updated June 2014.


Full Stack Web Developer from the University of Missouri with a broad base of experience in front-end solutions and user experience.
HTML5, CSS3, JavaScript(ES5/ES6), React.js, Bootstrap(3, 4), OOP, UI/UX, jQuery, API, PHP, MySQL, AJAX, JSON, Swift (Xcode), Adobe Suite (Audition, Premiere)
Math Emphasis
800+ hours of web development focused programming over the course of 12 weeks including weekly deadlines and project oriented goals
At MINDSEYE, I served as the first point of contact for customers seeking technical support over the phone or e-mail. I was responsible for maintaining working knowledge of the current software and versions in order to commute clearly and effectively with clients of lesser technical knowledge. Along with providing excellent customer support, I helped manage and create new accounts working directly with our clients.
Before college I worked part time at an AutoSpa car wash where I was responsible for handling transactions with customers, interacting with them to take care of thier needs, and overall doing physical tasks. Moving into college, I began working at Harpos Bar and Grill where I would begin doing general labor until I eventually got my internship/job at MINDSEYE.
Team-based project management system/bugtracker developed in React.js.
Content management system to track students by grade and course.
Rock-band themed memory-match game written in JavaScript.